Re: After reboot fs with barrier faster deletes then fs with nobarrier

Timothy Shimmin
2007-06-28T05:01:03Z

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