Re: [RFC, PATCH] Reservation based ext3 preallocation

From: Andrew Morton
Date: Tue Mar 30 2004 - 13:39:12 EST

Badari Pulavarty <pbadari@xxxxxxxxxx> 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
> > 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.
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at
Please read the FAQ at