The standards require that the ordering of a directory is consistent, not that entries appear in the order they are added. Under ZFS, the order depends on the hashing algorithm (entry names + salt). Even with UFS, you are relying on implementation behavior with an empty directory, since it uses a linear array of entries. I imagine that if you created a few entries, deleted old ones, and created new ones, you'd find the ordering dependent on which files you deleted.
- Eric On Wed, Jul 25, 2007 at 02:41:05AM -0700, Zhigang Cui wrote: > Hi, > When testing NFSv4 on ZFS, I met a 'random' FAIL. > > The case does the followings: > Client via nfsh > 1. create dir on server > 2. create file1 with short name under dir > 3. create file2 with long name under dir > 4. Call Readdir on dir with maxcount=96 and dircount=1024 > 5. Check the result, expect "OK" > > But sometimes it returns TOOSMALL. If you are not familiar with NFS, it does > not matter. With DTrace, I got the follows: > -> rfs4_op_readdir > ... > -> fop_readdir > -> crgetmapped > <- crgetmapped > -> zfs_readdir > <- zfs_readdir > <- fop_readdir > -> fop_rwunlock > -> fs_rwunlock > <- fs_rwunlock > <- fop_rwunlock > -> nfs4_readdir_getvp > | nfs4_readdir_getvp:entry > > Trace arg1 of nfs4_readdir_getvp:entry, it shows sometimes it is file1, > sometimes it is file2. I expect it is always file1 just like in UFS. Checking > inodes of dir, file1 and file2, they are always in ascending order. > > Does anyone has ideas on it? > > Thanks, > -- > This messages posted from opensolaris.org > _______________________________________________ > zfs-code mailing list > zfs-code at opensolaris.org > http://mail.opensolaris.org/mailman/listinfo/zfs-code -- Eric Schrock, Solaris Kernel Development http://blogs.sun.com/eschrock
