bug-coreutils
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [PATCH] ls -i: print consistent inode numbers also for mount points


From: Jim Meyering
Subject: Re: [PATCH] ls -i: print consistent inode numbers also for mount points
Date: Mon, 31 Aug 2009 16:23:59 +0200

Pádraig Brady wrote:
...
>> Yep, it has some performance impact...
>> checked `time ./ls -i1R /home /dev /usr /var /lib >myinodes with
>> approximate number of 31k dirs, 450k files on ext3
>>
>> and results are
>> old binary without the patch:
>> real    2m5.631s
>> user    0m3.012s
>> sys     0m4.815s
>>
>> new binary:
>> real    6m8.560s
>> user    0m3.947s
>> sys     0m30.572s
>
> So there was a lot more disk access with the new binary.

As expected.  The new version has to stat every single file.
The optimized one could deal with a 1-million-entry directory
with a single stat call (solely for the directory).

> but the NEWS suggests that should only be the case for
> "systems with dysfunctional readdir".

Currently, as far as I know, all systems except Cygwin
have a dysfunctional readdir.

On a modern system with lots of RAM and a hot cache, listing 238,000
inodes takes about twice as long:

  $ env time ./ls -i1R /home /dev /usr /var /lib > /t/inodes
  0.34user 0.95system 0:01.29elapsed 99%CPU (0avgtext+0avgdata 0maxresident)k
  0inputs+0outputs (0major+761minor)pagefaults 0swaps
  0.34user 0.94system 0:01.29elapsed 99%CPU (0avgtext+0avgdata 0maxresident)k
  0inputs+0outputs (0major+761minor)pagefaults 0swaps

  $ env time /bin/ls -i1R /home /dev /usr /var /lib > /t/inodes
  0.31user 0.29system 0:00.65elapsed 93%CPU (0avgtext+0avgdata 0maxresident)k
  80inputs+0outputs (2major+750minor)pagefaults 0swaps
  0.31user 0.30system 0:00.61elapsed 99%CPU (0avgtext+0avgdata 0maxresident)k
  0inputs+0outputs (0major+752minor)pagefaults 0swaps
  0.29user 0.30system 0:00.60elapsed 99%CPU (0avgtext+0avgdata 0maxresident)k
  0inputs+0outputs (0major+751minor)pagefaults 0swaps

But as you can read in that year old thread, we found no
widely-used application that relies on the performance of ls -i.




reply via email to

[Prev in Thread] Current Thread [Next in Thread]