DragonFly hammer List (threaded) for 2009-04
DragonFly BSD
DragonFly hammer List (threaded) for 2009-04
[Date Prev][Date Next]  [Thread Prev][Thread Next]  [Date Index][Thread Index]

Re: NetBSD hammer with fuse and hammerread


From: Oliver Fromme <check+ki8f3d00rswr5wy6@xxxxxxxxxx>
Date: 17 Apr 2009 07:32:09 GMT

Jeremy C. Reed wrote:
 > Prompted by Daniel's FUSE work, I tried it on NetBSD/amd64 5.0_RC3.
 > [...]
 > Problems:
 > - doesn't have number of links for directory (maybe causes find problem 
 >        shown below)
 > [...]
 > And a find problem (doesn't descend):

The fts(3) functions (used by find(1)) use an optimization
to avoid stat(2) calls.  If a file system supports hard
links, it is assumed that the link count on a directory
specifies the number of its (sub)directory entries.
This can speed up traversals considerably.

However, that assumption breaks if the link counts on
directories are smaller than the actual number of sub-
directories.

Therefore, the DragonFly BSD and FreeBSD fts(3) code uses
that optimization only for "UFS-like" file systems that are
assumed to have reliable link counts on directories.  The
list of such file systems is currently ufs, nfs, nfs4 and
ext2fs.

NetBSD does not have that restriction; it seems to always
use the optimization if the file system supports hard links
at all and has the usual "." and ".." entries.  That's why
the FUSE HAMMER module breaks fts(3) -- and thus find(1) --
on NetBSD.

For reference, here's the NetBSD code (in particular, see
the comments starting at line 611 and line 663):

http://cvsweb.netbsd.org/bsdweb.cgi/src/lib/libc/gen/fts.c?rev=1.38

And this is the DF and FreeBSD code (see the list of "UFS-
like" file systems starting at about line 90):

http://gitweb.dragonflybsd.org/dragonfly.git/blob_plain/HEAD:/lib/libc/gen/fts.c

http://www.freebsd.org/cgi/cvsweb.cgi/src/lib/libc/gen/fts.c?rev=1.30

Maybe NetBSD should adopt that change.  Also, I think
it wouldn't be bad if HAMMER filled the link counts on
directories with useful values, if that's technically
feasible.  Note that it doesn't hurt if the count is
too large, but it _does_ hurt if it's too low, because
a too low value causes premature break in fts(3) when
looking for subdirectories.

Best regards
   Oliver

-- 
Oliver Fromme, secnetix GmbH & Co. KG, Marktplatz 29, 85567 Grafing b. M.
Handelsregister: Registergericht Muenchen, HRA 74606,  Geschäftsfuehrung:
secnetix Verwaltungsgesellsch. mbH, Handelsregister: Registergericht Mün-
chen, HRB 125758,  Geschäftsführer: Maik Bachmann, Olaf Erb, Ralf Gebhart

FreeBSD-Dienstleistungen, -Produkte und mehr:  http://www.secnetix.de/bsd



[Date Prev][Date Next]  [Thread Prev][Thread Next]  [Date Index][Thread Index]