[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: FTS not ready for a remount during traversal
From: |
Kamil Dudka |
Subject: |
Re: FTS not ready for a remount during traversal |
Date: |
Wed, 4 Nov 2009 18:19:26 +0100 |
User-agent: |
KMail/1.9.10 |
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