On 18/01/16 16:25, Pádraig Brady wrote: > On 18/01/16 16:10, Kamil Dudka wrote: >> 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)? > > Maybe. But I'm also thinking it might mean we > can't enable this optimization for NFS > as the implementations are too disparate in this regard? > > It seems prudent for example to disable this > optimization for the imminent coreutils 8.25 release :(
Patch attaced
>From 85717b68b03bf85016c5079fbbf0c8aa2b182ba6 Mon Sep 17 00:00:00 2001 From: =?UTF-8?q?P=C3=A1draig=20Brady?= <p...@draigbrady.com> Date: Mon, 18 Jan 2016 17:29:28 +0000 Subject: [PATCH] fts: don't unconditionally use leaf optimization for NFS NFS st_nlink are not accurate on all implementations, leading to aborts() if that assumption is made. See <https://bugzilla.redhat.com/1299169> * lib/fts.c (leaf_optimization_applies): Remove NFS from the white list, and document the issue. --- ChangeLog | 9 +++++++++ lib/fts.c | 19 ++++++++++--------- 2 files changed, 19 insertions(+), 9 deletions(-) diff --git a/ChangeLog b/ChangeLog index 80d496e..fac13e6 100644 --- a/ChangeLog +++ b/ChangeLog @@ -1,3 +1,12 @@ +2016-01-18 Pádraig Brady <p...@draigbrady.com> + + fts: don't unconditionally use leaf optimization for NFS + NFS st_nlink are not accurate on all implementations, + leading to aborts() if that assumption is made. + See <https://bugzilla.redhat.com/1299169> + * lib/fts.c (leaf_optimization_applies): Remove NFS from + the white list, and document the issue. + 2016-01-15 Paul Eggert <egg...@cs.ucla.edu> KO Myung-Hun <k...@chollian.net> diff --git a/lib/fts.c b/lib/fts.c index 7e9aca6..2c9df2f 100644 --- a/lib/fts.c +++ b/lib/fts.c @@ -718,22 +718,23 @@ leaf_optimization_applies (int dir_fd) switch (fs_buf.f_type) { - case S_MAGIC_NFS: - /* NFS provides usable dirent.d_type but not necessarily for all entries - of large directories. See <https://bugzilla.redhat.com/1252549>. */ - return true; - /* List here the file system types that lack usable dirent.d_type info, yet for which the optimization does apply. */ case S_MAGIC_REISERFS: case S_MAGIC_XFS: return true; + /* Explicitly list here any other file system type for which the + optimization is not applicable, but need documentation. */ + case S_MAGIC_NFS: + /* NFS provides usable dirent.d_type but not necessarily for all entries + of large directories, so as per <https://bugzilla.redhat.com/1252549> + NFS should return true. However st_nlink values are not accurate on + all implementations as per <https://bugzilla.redhat.com/1299169>. */ + /* fall through */ case S_MAGIC_PROC: - /* Explicitly listing this or any other file system type for which - the optimization is not applicable is not necessary, but we leave - it here to document the risk. Per http://bugs.debian.org/143111, - /proc may have bogus stat.st_nlink values. */ + /* Per <http://bugs.debian.org/143111> /proc may have + bogus stat.st_nlink values. */ /* fall through */ default: return false; -- 2.5.0