Messages in this thread | | | Date | Tue, 13 Apr 2004 23:01:02 -0500 | From | Matt Mackall <> | Subject | Re: [RFC] extents,delayed allocation,mballoc for ext3 |
| |
On Tue, Apr 13, 2004 at 11:28:57PM +0400, alex@clusterfs.com 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@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
| |