Re: Odd Block allocation behavior on Reiser3

[Sonny Rao <sonny@burdell.org>]

On Tue, Aug 10, 2004 at 02:50:13PM -0400, 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.
>

Is that "oid_groups" option present in the stock 2.6.7 kernel?  It
didn't like that mount option, and a cursory grep for "oid_groups" in
linux-2.6.7/fs/reiserfs/* doesn't show me anything.  The "skip_busy"
option worked but didn't seem to change allocation behavior.

Another piece of information that pointed me at possible fragmentation
came from iostat.  It shows during my tests that the average request
size is about 745 sectors while on ext3 I see an average request size
of about 900 sectors.   
The io size limit on the kernel was 512k, so the max size should have
been about 1024 sectors.  On JFS and XFS I did see the average request size
very close to 1024 sectors, and the best performance.

So, even though you are probably correct about the 2 block gaps being
metadata, the iostat data could be interpreted to indicate this
behavior is hurting performance relative to the other filesystems on
this particular test.

I'm planning on trying out 2.6.8-rc4 soon.

Sonny