Re: [RFC, PATCH] Reservation based ext3 preallocation

[Andrew Morton]

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

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

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  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/