This message is re-posted from the zfs-discuss mailing list. One of my two replies recommended that I send my questions to this mailing list.
It appears as though zfs reports the size of a directory to be one byte per file. Traditional file systems such as ufs or ext3 report the actual size of the data needed to store the directory or some slightly more representative approximation of the largest size the directory has ever been. This causes some trouble with the default behavior of some nfs clients (linux) which decide to to use a readdirplus call when directory contents are small vs a readdir call when the contents are large. We've found this particularly troublesome with Maildir style mail folders. The speedup by not using readdirplus is a factor of 100 in this particular situation. While we have a work around it would seem that this non-standard behavior might cause trouble for others and in other areas. Are there any suggestions for dealing with this difference and/or why zfs does not represent its directory sizes in a more traditional manner? >From the linux kernel source. ./fs/nfs/inode.c:#define NFS_LIMIT_READDIRPLUS (8*PAGE_SIZE) ie. ZFS zfshost:~/testdir> ls -1 | wc -l 330 zfshost:~/testdir> stat . File: `.' Size: 332 Blocks: 486 IO Block: 32768 directory Device: 29h/41d Inode: 540058 Links: 2 Access: (0775/drwxrwxr-x) Uid: ( 2891/ banal) Gid: ( 101/ film) Access: 2008-11-05 18:40:16.000000000 -0800 Modify: 2009-09-01 16:09:52.782674099 -0700 Change: 2009-09-01 16:09:52.782674099 -0700 ie. ext3 ext3host:~/testdir> ls -1 | wc -l 330 ext3host:~/testdir> stat . File: `.' Size: 36864 Blocks: 72 IO Block: 4096 directory Device: 807h/2055d Inode: 23887981 Links: 2 Access: (0775/drwxrwxr-x) Uid: ( 2891/ banal) Gid: ( 101/ film) Access: 2009-09-21 13:44:00.000000000 -0700 Modify: 2009-09-21 13:44:31.000000000 -0700 Change: 2009-09-21 13:44:31.000000000 -0700 Thanks, Chris -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://mail.opensolaris.org/pipermail/zfs-code/attachments/20090925/5900b982/attachment.html>
