Re: Why does -inum require stat(2)?

[James Youngman]

On Tue, Sep 23, 2008 at 3:11 PM, George Spelvin <address@hidden> wrote:
> "James Youngman" <address@hidden> wrote:
>> Based on what you write I would assume that this is true for both the
>> find and the oldfind executables built in all even vaguely-recent
>> findutils releases.
>
> Er... I'm not familiar with the oldfind executable.  I'm using the
> Debian-compiled amd64 4.4.0 binary.

Ah.   If you build from source, you get two executables.   One is
built with fts, the other without.   Their names are goverened by the
--with-fts configure option:

If ---with-fts: "find" has fts and the other binary is "oldfind"
If --without-fts: "find" lacks fts and the other binary is "ftsfind".

It had been my plan to wholly retire "oldfind" before now, but there
are some lingering performance problems with the fts version, largely
caused by the fact that the fit between find's needs and the fts API
is good but not perfect.


>> But in the case where the file we're currently considering is a
>> non-directory, it can't also be a mount point.   Therefore where d_ino
>> is available we should be able to trust it (famous last words :).
>> Using stat only for directories is essentially zero cost, since we
>> need to stat them as part of the traversal operations.
>
> Yup.  I tested that Linux bind mounts (which can mount a file!)
> alter d_ino.
>
> Do you have any advice on extending the savedir code to include d_ino?

"go for it".   :)

But, while oldfind does use savedir, ftsfind does not.   It uses fts()
from gnulib/lib/fts.c and that's part of gnulib.

I'd certainly accept a change that only improved oldfind, but as you
noticed that is not the version shipped wiht most distributions.
ftsfind has several advantages, but the principal ones are that it
handles deep hierarchies much better and it's significantly cleaner in
its design.

> For a few days, I'm enthused about "scratching my itch" and can
> dig into it, although I'd like some advice on making a "architectural"
> change like that.

This is something that find has needed for quite a while.   There is a
somewhat more general problem too - the ftsfind program itself seems
to stat files that fts() already stated, I think.

There may also be other opportunities for improvement, too.  For
example I have read that sorting your list of filenames by inode
number can significantly reduce the amount of head movement needed to
stat all the files in a directory.  But I don't know for sure if that
is still true with modern filesystems.


> And if you'll tell me how to do it, I'll do it as a work for hire for
> you and you can assign it to the EFF.  (17 USC 101: "Works Made for
> Hire [...] (2) a work specially ordered or commissioned for use as a
> contribution to a collective work [...] if the parties expressly agree
> in a written instrument signed by them that the work shall be considered
> a work made for hire.")

Great.   That is the common practice at GNU (we call the written
instrument a "copyright assignment").


Thanks for helping!

James.