On Wednesday 09 December 2015 10:35:25 Pádraig Brady wrote: > On 09/12/15 06:34, Kamil Dudka wrote: > > The flag is needed to implement the -noleaf option of find. > > * lib/fts.c (link_count_optimize_ok): Implement the FTS_NOLEAF flag. > > * lib/fts_.h (FTS_NOLEAF): New macro, shifted conflicting constants. > > Is this exposed to fix issues with certain file systems, > or just in case there may be issues, or support easily > testing find without the leaf optimization?
All of the above I would say. We can never verify that it works properly for all white-listed file systems in all kernel versions (and all their supported configurations). There should always be a way for the user to disable the optimization if needed, either for debugging, or to work around a file system bug. > I see Jim said the current FTS implementation > would make -noleaf a no-op there: > https://lists.gnu.org/archive/html/bug-gnulib/2008-12/msg00280.html Yes but it has never been reflected in find's documentation so the current behavior hardly matches what users would expect. > cheers, > Pádraig. > > p.s. I see that find does a stat per file on XFS, > while d_type can be used to distinguish dirs there. > On XFS DT_DIR is set for dirs and DT_UNKNOWN otherwise. I am afraid this is not sufficient for FTS to eliminate all calls to stat() unless it is guaranteed that DT_UNKNOWN is never returned for a directory. > I wonder is there some optimization we could do for that case. After quick check I can see the leaf optimization applies to that case too. Given the fact that it was already enabled by default in RHEL-5 findutils, it is difficult to explain why the feature is not available in the latest upstream. Kamil
