Re: FTS not ready for a remount during traversal

[Jim Meyering]

Kamil Dudka wrote:
> On Wednesday 04 of November 2009 16:12:42 Eric Blake wrote:
>> We have already asked the kernel folks if they would be willing to make
>> readdir () report accurate d_ino values for mount points, and they
>> complained that it would be too expensive to guarantee correct d_ino
>> information compared to the number of clients that don't care whether it is
>> correct.  But they did mention the possibility of perhaps adding some sort
>> of flag, or a new d_type, which identifies mount points, and which the
>> application can then use to make it obvious that a stat() is necessary to
>> get reliable inode information for _just that directory_.
>
> I completely agree that such a flag would be generally helpful. However we
> need to get coreutils working with current kernels anyway.
>
>> This seems like yet another case where convincing the kernel folks to GIVE
>> us this information would be helpful.  Just knowing whether a directory is
>> a mount point will give us the power to know whether we need to stat() it
>> after automounting, without penalizing the common case of a directory that
>> is not a mount point.  Since mount point semantics are squarely on the
>> shoulders of the kernel, please consider pushing harder for a fix to come
>> from the kernel, rather than a workaround in coreutils.
>
> I would contend the patch is a workaround. From my point of view it's
> a *bugfix* for coreutils (and other gnulib-based projects). If you think the
> kernel's behavior is incorrect, please refer to a specification saying this.

The part about distinct directories having identical device/inode
numbers is definitely a bug, but that was incidental.

POSIX does not specify behavior in the presence of mount points.

> My point is that there is in fact no performance impact caused by the patch

Here's an example with fewer than 5000 directories
that demonstrates a 23% impact:

    http://lkml.org/lkml/2009/11/5/366

> and what we do now is a premature optimization. The FTS module is simply
> based on an assumption which is not guaranteed to hold in general.