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.
--Tim
|