On Thu, 28 Jun 2007 06:00:46 +0100, Timothy Shimmin <tes@xxxxxxx> wrote:
David Chinner wrote:
On Wed, Jun 27, 2007 at 06:58:29PM +0100, Szabolcs Illes wrote:
Hi,
I am using XFS on my laptop, I have realized that nobarrier mount
options sometimes slows down deleting large number of small files,
like the kernel source tree. I made four tests, deleting the kernel
source right after unpack and after reboot, with both barrier and
nobarrier options:
>> mount opts: rw,noatime,nodiratime,logbsize=256k,logbufs=2
>> illes@sunset:~/tmp> tar xjf ~/Download/linux-2.6.21.5.tar.bz2 &&
sync && reboot
>> After reboot:
>> illes@sunset:~/tmp> time rm -rf linux-2.6.21.5/
>> real 0m28.127s
>> user 0m0.044s
>> sys 0m2.924s
>> mount opts: rw,noatime,nodiratime,logbsize=256k,logbufs=2,nobarrier
>> illes@sunset:~/tmp> tar xjf ~/Download/linux-2.6.21.5.tar.bz2 &&
sync && reboot
>> After reboot:
>> illes@sunset:~/tmp> time rm -rf linux-2.6.21.5/
>> real 1m12.738s
>> user 0m0.032s
>> sys 0m2.548s
>> It looks like with barrier it's faster deleting files after reboot.
>> ( 28 sec vs 72 sec !!! ).
Of course the second run will be faster here - the inodes are already
in
cache and so there's no reading from disk needed to find the files
to delete....
That's because run time after reboot is determined by how fast you
can traverse the directory structure (i.e. how many seeks are
involved). Barriers will have little impact on the uncached rm -rf
results,
But it looks like barriers _are_ having impact on the uncached rm -rf
results.
and the same happens on my desktop pc which is much more faster, 64 bit
dual core P4, sata drive, etc.
nobarrier:
+ echo 3 > /proc/sys/vm/drop_caches
+ rm -rf /root/fs/linux-2.6.21.5 /root/fs/x.tar
real 0m12.526s
user 0m0.016s
sys 0m1.244s
barrier:
+ echo 3 > /proc/sys/vm/drop_caches
+ rm -rf /root/fs/linux-2.6.21.5 /root/fs/x.tar
real 0m6.784s
user 0m0.032s
sys 0m1.244s
Szabolcs
--Tim
|