Re: FTS not ready for a remount during traversal

[Kamil Dudka]

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.

My point is that there is in fact no performance impact caused by the patch 
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.

Kamil