bug-gnulib
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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


From: Kamil Dudka
Subject: Re: [PATCH 1/2] fts: introduce the FTS_NOLEAF flag
Date: Mon, 18 Jan 2016 17:10:13 +0100
User-agent: KMail/4.14.10 (Linux/4.2.8-300.fc23.x86_64; KDE/4.14.14; x86_64; ; )

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



reply via email to

[Prev in Thread] Current Thread [Next in Thread]