Re: [RFC, PATCH] Reservation based ext3 preallocation

[Andrew Morton <akpm@osdl.org>]

Badari Pulavarty <pbadari@us.ibm.com> wrote:
>
> On Tuesday 30 March 2004 01:45 am, Andrew Morton wrote:
> 
> Andrew,
> 
> > - Using ext3_find_next_zero_bit(bitmap_bh->b_data in
> >   alloc_new_reservation() is risky.  There are some circumstances when you
> >   have a huge number of "free" blocks in ->b_data, but they are all unfree
> >   in ->b_committed_data.  You could end up with astronomical search
> >   complexity in there.  You should search both bitmaps to find a block
> >   which really is allocatable.  Otherwise you'll have
> >   ext3_try_to_allocate() failing 20,000 times in succession and much CPU
> >   will be burnt.
> 
> Can you explain this a little more ?  What does b->data and b->commited_data 
> represent ?  We are assuming that b->data will always be uptodate. 

The comment Alex pointed to is splendid ;)

> May be we should use ext3_test_allocatable() also.

I think so.

> > - There's a little program called `bmap' in
> >   http://www.zip.com.au/~akpm/linux/patches/stuff/ext3-tools.tar.gz which
> >   can be used to dump out a file's block allocation map, to check
> >   fragmentation.
> 
> Thanks. will use that. We are using debugfs for now. Do you have any tools
> to dump out whats in journal ? I want to understand log format etc.. 
> Just curious.

I cannot think of any.  It wouldn't surprise me if e2fsck had a debug mode
which printed out this info, but I have not looked.

> >
> > Apart from that, looking good.  Where are the benchmarks? ;)
> 
> We are first concentrating on tiobench regression. We see clear
> degrade with tiobench on ext3, since it creates lots of files in the
> same directory. Once we are happy with tiobench, we go for others
> kernel untars, rawiobench etc.

OK..  dbench on SMP hardware shows poor layout also.