Re: make getdents/readdir POSIX compliant wrt mount-point dirent.d_ino

[Theodore Tso <tytso@mit.edu>]

On Wed, Nov 04, 2009 at 08:29:00PM +0100, Jim Meyering wrote:
> One way to accommodate the current automount semantics, is to make fts.c
> incur, _for every directory traversed_, the cost of an additional
> stat (fstatat, actually) call just in case this happens to be one of
> those rare mount points.
> 
> I would really rather not pessimize most[*] hierarchy-traversing
> command-line tools by up to 17% (though usually far less) in order
> to accommodate device-number change semantics that arise
> for an automountable directory.

I must be missing something.  How do you come up with the 17% penalty
figure?  And what does this actually mean in real life?

stat() in Linux is fast.  Really fast.  A quick benchmark clocks
stat() on my system at 0.814 *microseconds* in the warm cache case,
and if you're stating a directory that you've traversed, odds are
extremely high that it will still be in the cache.

My entire laptop root filesystem has 53,934 directories, so an extra
stat() per directory translates to an extra 43 milliseconds, assuming
I needed to walk my entire root filesystem.  It's really hard to see
why kernel developers should get worked up into a lather over that
kind of "performance penalty".

Regards,

						- Ted