[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
- Re: [PATCH 1/2] fts: introduce the FTS_NOLEAF flag,
Kamil Dudka <=