Re: stat() order performance issues

[Jim Meyering]

Phillip Susi <address@hidden> wrote:
> Jim Meyering wrote:
>> That's good, but libc version matters too.
>> And the kernel version.  Here, I have linux-2.6.18 and
>> Debian/unstable's libc-2.3.6.
>
> How does the kernel or libc version matter at all?  What matters is the
> on disk filesystem layout and how it is not optimized for fetching stat
> information on files in what is essentially a random order, instead of

For some cases, it matters a lot.  I.e. for ls -i.
If your libc's readdir support doesn't put file system information
into struct dirent, then you're out of luck.
Likewise, if your OS is too old.

> inode order.  In the case of ext2/3, the inodes are stored on disk in
> numerical order, and for reiserfs, they tend to be stored in order, but
> don't have to be.  On ext2/3 I believe file names are stored in the
> order they were created in, and on reiserfs, they are stored in order of
> their hash.  In both cases the ordering of inodes and the ordering of
> names returned from readdir are essentially randomly related.
>
> Anyhow, I am running kernel 2.6.15 and libc 2.3.6.
>
>> 10-15 minutes is very bad.
>> Something needs an upgrade.
>
> Or a bugfix/enhancement, unless there already is a newer version of
> coreutils that stats in inode order.  My version of coreutils is 5.93.

Um... that's over a year old.  The latest is coreutils-6.7.
And yes, you'll notice improvements in this regard.