|
From: | James Youngman |
Subject: | Re: [PATCH 1/2] fts: introduce the FTS_NOLEAF flag |
Date: | Sat, 16 Jul 2016 14:05:13 +0100 |
On Monday 21 December 2015 15:01:56 Kamil Dudka wrote:
> On Monday 21 December 2015 00:05:51 Pádraig Brady wrote:
> > On the other hand we've had no reports of issues with the
> > existing auto config done by FTS.
>
> Because the leaf optimization has been enabled for reiserfs only until now.
> I suspect that NFS will not be that easy and such file system issues might
> be difficult to debug without the -noleaf option actually implemented.
So we have the first bug report about the leaf optimization causing problems
to users of find(1):
https://bugzilla.redhat.com/1299169
Is this a reason to implement the -noleaf option of find (and consequently
the FTS_NOLEAF flag of gnulib's FTS)?
Kamil
> > In my experience one
> > should jump through hoops to avoid config where possible.
> > Until we see a case where dirent.d_type is accurate while
> > noleaf is not appropriate, then I'm inclined to avoid the config.
> > If this was an issue then there would need to be associated
> > -noleaf patches to find(1), and also other FTS using tools.
>
> That sounds like a reasonable approach for tools that do not implement any
> -noleaf option yet. However, GNU find has provided this option since 1996
> (if not even longer) and the option has never been properly deprecated.
>
> > I've applied the patch to ensure noleaf optimization is
> > enabled for NFS, and also applied my patch enabling it for XFS.
> >
> > thanks,
> > Pádraig.
>
> Thank you for applying those patches!
>
> Kamil
[Prev in Thread] | Current Thread | [Next in Thread] |