Subject: Re: nfs bug?
To: None <wrstuden@netbsd.org>
From: YAMAMOTO Takashi <yamt@mwd.biglobe.ne.jp>
List: current-users
Date: 06/03/2004 10:02:09
> I think I found the general area of the problem, though I don't know the 
> code well-enough to continue. The fts source has the following comment:
> 
>  * The real slowdown in walking the tree is the stat calls.  If FTS_NOSTAT is
>  * set and it's a physical walk (so that symbolic links can't be directories),
>  * we can do things quickly.  First, if it's a 4.4BSD file system, the type
>  * of the file is in the directory entry.  Otherwise, we assume that the number
>  * of subdirectories in a node is equal to the number of links to the parent.
>  * The former skips all stat calls.  The latter skips stat calls in any leaf
>  * directories and for any files after the subdirectories in the directory have
>  * been found, cutting the stat calls by about 2/3. 
> 
> I think the problem is that the code's making an assumption which isn't 
> true for this NFS server. Unfortunately I don't understand the code 
> well-enough to know what exactly that assumption is. :-)

iirc, fts assumes that, number of sub directory == (nlink - 2).
ie. scanning a directory, if it has already found (nlink - 2) sub directories,
it consider that none of subsequent entries is a directory (and optimize
out stat() calls).

in the case of "mkdir -p foo/bar/baz; rm -r foo",
i guess, fts considered that "foo/bar" was not a directory.

YAMAMOTO Takashi