Phillip Susi <[EMAIL PROTECTED]> 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. _______________________________________________ Bug-coreutils mailing list [email protected] http://lists.gnu.org/mailman/listinfo/bug-coreutils
