Re: [RFC] extents,delayed allocation,mballoc for ext3

From: Matt Mackall
Date: Tue Apr 13 2004 - 23:02:48 EST


On Tue, Apr 13, 2004 at 11:28:57PM +0400, alex@xxxxxxxxxxxxx wrote:
>
> these patches implement several features for ext3:
> - extents
> - multiblock allocator
> - delayed allocation (a.k.a. allocation on flush)
>
>
> extents
> =======
> it's just a way to store inode's blockmap in well-known triples
> [logical block; phys. block; length]. all the extents are stored
> in B+Tree. code is splitted in two parts:
> 1) generic extents support
> implements primitives like lookup, insert, remove, walk
> 2) VFS part
> implements ->getblock() and ->truncate() methods

I'm going to assume that there's no way for ext3 without extents
support to mount such a filesystem, so I think this means changing the
FS name. Is there a simple migration path to extents for existing filesystems?

> multiblock allocator
> ===================
> the larger extents the better. the reasonable way is to ask block
> allocator to allocate several blocks at once. it is possible to
> scan bitmaps, but such a scanning isn't very good method. so, here
> is mballoc - buddy algorithm + possibility to find contig.buddies
> fast way. mballoc is backward-compatible, buddies are stored on a
> disk as usual file (temporal solution until fsck support is ready)
> and regenerated at mount time. also, with existing block-at-once
> allocator it's impossible to write at very high rate (several
> hundreds MB a sec). multiblock allocator solves this issue.

Similar questions here.

> NOTE: don't try to use it in production. all the patches (probably
> excluding extents) are pre-pre-alpha. because of size I put patches
> in ftp://ftp.clusterfs.com/pub/people/alex/2.6.4-mm2/

You might also mention that on-disk format issues such as endian
layout are not finalized.

--
Matt Mackall : http://www.selenic.com : Linux development and consulting
-
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/