[ardour-dev] Re: filefrag tool

[Doug McLain]

Theodore Ts'o wrote:

>On Mon, Jan 24, 2005 at 03:50:40AM +0000, Doug McLain wrote:
>  
>
>>In #ardour today we did alot of discussing and testing of file 
>>fragmentation, and determined that the performance problem described in 
>>mantis #864 is caused in a large part by the interleaving of a sessions 
>>wav files and peak files.  The tool 'filefrag' has been a great tool 
>>(using the -v switch) in conducting these experiments.  The only thing 
>>it lacks is the output of first and last blocks.  Below is the mod that 
>>adds that info to the output.  Here is a link to the package that 
>>filefrag belongs to:
>>
>>http://e2fsprogs.sourceforge.net/
>>    
>>
>
>Thanks for the patch.
>
>If you are using the latest 2.6 kernel with the block allocation
>reservations patch, that should help this problem, at least partially.
>Another (admittedly gross kludge) is to create a temporary directories
>for the wav and the peak files, so that the wav and the peak files are
>created in different directories.  That way ext2/3 will allocate them
>to use different block groups, thus keeping the blocks from being
>interleaved.  (Of course, you will still see performance problems when
>you are writing, since the disk will be seeking back and forth;
>however, for reading the file will be contiguous, and improve that
>performance.)
>
>In general, this is a hard problem.  Actually, turning off write
>reservations so that the blocks are interleaved for the wav and peak
>files might actually lead to better performance when writing the files
>(since the disk won't have to seak back and forth), but may result in
>worse performance when you read them later.  So it's important to know
>what you are trying to optimize.n
>
>  
>
>>Even though its part of an extX tools package, it seems to be fs 
>>independant.  I tried it on resierfs too, seems to work well.
>>    
>>
>
>Yes, it is filesystem independent, although it does have some ext2/3
>specific knowledge which it uses when calculating what it thinks to be
>the optimal best amount of fragmentation.
>
>Cheers,
>
>						- Ted
>
>  
>