On Sat, Jun 09, 2007 at 10:16:34PM +0200, [EMAIL PROTECTED] wrote: > > >Oh, I see, this is bug 6479267: st_size (struct stat) is unreliable in > >ZFS. Any word on when the fix will be out? > > It's a bug in scandir (obviously) and it is filed as such. > > Does scandir fail on zfs because of this or does scandir needs to > reallocate and does it use the size as first order estimate?
I encountered the problem in NetBSD's scandir(), when reading off a Solaris NFS fileserver with ZFS filesystems. I've already filed a bug report with NetBSD. They were using the st_size, divided by 24, to determine how much memory to allocate with malloc() before reading in the directory entries. All without any sanity checking. I've found other programs that make similar assumptions, including the hard-coding of "24" instead of "sizeof dirent". What was the reason to make ZFS use directory sizes as the number of entries rather than the way other Unix filesystems use it? This message posted from opensolaris.org _______________________________________________ zfs-discuss mailing list zfs-discuss@opensolaris.org http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
