For the case of mkfile it doesn't really matter, but AFAIK zfs provides more guarantees than ufs does. Ufs without logging guarantees very little (esp. if more or less synchronous metadata updates are turned off e.g. with fastfs). Ufs with logging more or less guarantees filesystem consistency (and therefore metadata updates that might affect filesystem consistency). Zfs (I think) guarantees not only metadata consistency, but also some measure of data consistency (or at least error detection), although that might not fully apply without O_SYNC, and of course says nothing about logical consistency from the program's perspective (for which it has to take some extra effort).
The price for the additional guarantees likely varies according to the workload; for hopefully most situations, zfs gains enough performance that there is no price. But providing better performance for _all_ situations with such a very different implementation must be difficult indeed; or to put it the other way around, I'm reasonably sure that providing poorer performance under any particular condition was _not_ intentional! Still, I'd hope that if enough info can be provided to replicate pathological cases, something would be done to improve the performance for them. Making it more interesting is how mkfile writes. The S8 FCS source looks like it wrote 8K chunks always. The current source looks like it tries to write st_blksize chunks, which is at least more adaptive; one could argue, correctly so. I notice you didn't mention the recordsize for the zfs filesystem in question; that may have some bearing (a small recordsize could be an issue, at least if you've set it below the 128K default). As a practical matter, last I read, swapping to a file on a zfs filesystem isn't supported anyway, so the most common use of files created with mkfile wouldn't apply to zfs. Unless its behavior is representative of other programs (look at the mkfile source and decide for yourself...), I don't know how much light is shed by mkfile as a test case (except of course that under some circumstances, zfs doesn't outperform ufs). One think I'm not crazy about with mkfile, BTW, is that it always writes that last buffer first, not just when creating a sparse file (-n option), but always. Personally, I think it ought not do that when writing non-sparsely, if only because that seems to me to subvert whatever effort the filesystem might make at keeping the file contiguous. While it doesn't address the issue of zfs performance under your particular conditions and with the present implementation of mkfile, I suspect mkfile could be rewritten to perform better. In particular, the use of ftruncate() and (on a 64-bit system) one giant mmap(), with a zero assigned to the first byte of each page (and perhaps with the largest supported pages being used), might well be faster than what it does now. Or perhaps behaving in whatever sort of way would have improved the ufs+directio case might also be better in other cases too. At any rate, I suspect that its present implementation is simple rather than particularly fast. Since people persist in using it as a simplistic test case (although mkfile has indeed changed a bit over the years), perhaps there would be some (misleading, to be sure) perception benefit to speeding mkfile up a bit. This message posted from opensolaris.org _______________________________________________ perf-discuss mailing list perf-discuss@opensolaris.org
