[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: find -noleaf
Re: find -noleaf
Sun, 15 Apr 2007 12:51:49 +0100
On 3/20/07, Gregg Tracton <address@hidden> wrote:
I noticed in RHEL4 that the "default" syntax (with no command-line switches)
of the 'find' command has changed to *require* the -noleaf switch for
on AFS disks, CD-ROMs and some other file systems that do not adhere to the
*convention* of 2 hard links in each dirent.
I have no idea what version of findutils you are using, but the leaf
optimization has been the default in findutils for *years* (since
before the relase of 4.0, I think).
For a while now findutils has been automatically turning off the leaf
optimisation for directories where the link count is less than 2. I
would expect filesystems not honouring the traditional (but not
standards-enforced) semantics of directory hard link counts should
simply offer st_nlink=1 for directories.
Are you seeing behaviour which isn't consistent with these
assumptions? If so, precisely what are you seeing?
Please make the default be "no optimization" and allow a switch "-leaf"
that one may invoke if speed is an issue.
My intent is to detect this situation automatically.
- it appears that the optimization disabled by noleaf could have be
the find command examining the file system type, or testing that the
produces the right results before triggering it.
The problem with doing things this way is that reliably determining
the filesystem type can involve stat()ing all the mount points on the
system, which causes hangs on machines which are clients of
unresponsive NFS servers.
- i have written dozens of scripts, and have seen dozens more
distributed by redhat,
that this change will force to alter.
Well, it's not a change. But let's continue to investigate the
problem (please see my questions above).
- find -noleaf, Gregg Tracton, 2007/04/15
- Re: find -noleaf,
James Youngman <=