Don Cragun wrote: > Chris, > If ZFS is ever going to pass the test suites so we can claim > that ZFS meets POSIX and UNIX filesystem requirements, you'll find that > the conformance test suites will be trying things similar to what I've > been describing. The test suites certainly aren't perfect, but over > time they get more and more touchy about lies. If the test suites get > an EOVERFLOW when requesting information, they'll report an unresolved > status along with what they were trying to test, and specify that human > intervention (in this case an explanation) will be required to get > certification. If the test suite catches you in a lie, you'll have to > file for a test suite waiver and explain why the test suite is wrong. > If statvfs() says there are X files, blocks, ... available when there > are 2X or X+1, there is a very low chance of getting the waiver. At > that point you will have the option of not certifying your product or > fixing your code so it passes the test.
Don, Can you provide a concrete example of this? Eg: which standard requires what behavior, and how would the changes that Chris is proposing violate them? It's difficult for me to see how any reasonable test program could succeed under ZFS today but fail with Chris's changes. With ZFS, the number of blocks or files "available", while true, does not exactly and simply correspond to whether any future syscall will succeed or fail -- even in an otherwise idle system, even waiting "sufficiently long" for all changes to percolate through the system. This is due to metadata, compression, gang blocks, raid-z, snapshots, etc. This is somewhat true even in UFS -- indirect blocks have to come from somewhere. So for example, if there is X bytes of free space, you can not necessarily write X bytes to an existing file. If you can, there will not necessarily be 0 free bytes. Same goes for number of files available. To take the one example you mentioned, if X files are removed, on ZFS today the number of free files will not necessarily go up by X (nor necessarily by X or more, nor necessarily by X or less; the number of free files may even decrease!). This is because metadata is shared between files (there are many dnodes per block), and because of snapshots. Therefore applications can not make any assumption about how any action will affect the number of available files. --matt
