Re: [RFC, PATCH] Reservation based ext3 preallocation

Andrew Morton
2004-03-30T18:37:29Z

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.