Re: [RFC, PATCH] Reservation based ext3 preallocation

From: Andrew Morton
Date: Tue Mar 30 2004 - 04:47:37 EST

Mingming Cao <cmm@xxxxxxxxxx> wrote:
> Ext3 preallocation is currently missing.

I thing this is heading the right way.

- Please use u32 for block numbers everywhere. In a number of places you
are using int, and that may go wrong if the block numbers wrap negative
(I'm not sure that ext3 supports 8TB, but it's the right thing to do).

- 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.

- I suspect ext3_try_to_allocate_with_rsv() could be reorganised a bit to
reduce the goto spaghetti?

- Please provide a mount option which enables the feature, defaulting to

- Make sure that you have a many-small-file test. Say, untar a kernel
tree onto a clean filesystem and make sure that reading all the files in
the tree is nice and fast.

This is to check that the reservation is being discarded appropriately
on file close, and that those small files are contiguous on-disk. If we
accidentally leave gaps in between them the many-small-file bandwidth
takes a dive.

- There's a little program called `bmap' in which
can be used to dump out a file's block allocation map, to check

Apart from that, looking good. Where are the benchmarks? ;)
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