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
