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

Reply via email to