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>