Re: Odd Block allocation behavior on Reiser3

[Hans Reiser <reiser@namesys.com>]

Chris Mason wrote:

>On Tue, 2004-08-10 at 14:25, Chris Mason wrote:
>  
>
>>On Tue, 2004-08-10 at 13:52, Hans Reiser wrote:
>>    
>>
>>>Sonny Rao wrote:
>>>
>>>      
>>>
>>>>On Tue, Aug 10, 2004 at 12:16:39AM -0700, Hans Reiser wrote:
>>>> 
>>>>
>>>>        
>>>>
>>>>>Interesting.What happens without overwrite, that is, if you write more 
>>>>>files without deleting the old ones?
>>>>>   
>>>>>
>>>>>          
>>>>>
>>>>Below I made 24 one gigabyte files in sequence
>>>>All of them are similarly fragmented: 
>>>>data # filefrag *
>>>>datafile0: 268 extents found
>>>>
>>>>        
>>>>
>>>this could explain some reiser3 performance problems.   This is what 
>>>happens when I spend all my time chasing funding and don't spend it 
>>>reviewing code and benchmarks, sigh.
>>>
>>>Thanks for spotting this.  I would be curious if this is occuring near 
>>>the transition between unformatted nodes and their parents, or something 
>>>else.
>>>      
>>>
>>There have been a few threads on this on reiserfs-list
>>
>>singer:/data # dd if=/dev/zero of=foo bs=1MB count=1000
>>1000+0 records in
>>1000+0 records out
>>singer:/data # filefrag foo
>>foo: 1 extent found
>>
>>The new allocator really should be doing a better job here.
>>    
>>
>
>Hmpf, that's what I get for expecting filefrag to work properly on
>amd64.  The actual number of extents is 199, which is still better then
>268.  Using fibmap, the fragmentation percentage is still the same as
>ext3 (99.99% unfragmented) meaning the length between the extents is
>quite small.
>
>If you mount with:
>
>mount -o alloc=skip_busy:oid_groups
>
>You get 8 extents on a 1GB file.
>
>This is because the oid grouping tries much harder to isolate the file
>data from data from other files and metadata.  It is far from optimal
>for normal usage, but for huge files it works nicely.
>
>-chris
>
>
>
>
>  
>
For an empty filesystem there should be no fragmentation at all for big 
dds one after another, except at bitmap block boundaries.  Any other 
result indicates flawed code.  Remember, a hint of flawed code often 
leads to more than a trivial flaw when fully understood.