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

[Timothy Shimmin <tes@sgi.com>]

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