Re: [PATCH 1/2] fts: introduce the FTS_NOLEAF flag

[Kamil Dudka]

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