Re: [RFC] file extents for EXT3

[Jeff Garzik]

Alex Tomas wrote:
> hello all!
>
> there are several problems with old good method ext2/ext3
> use to store map of block for an inode. for example, ext3's
> truncate is quite slow. I think extents could solve this
> and some other troubles. so ...
>
>
> in fact, design is taken from htree modern ext2/ext3 uses. in constrast with
> htree, it isn't backward-compatible.

Neat.  I really like extents, and think this is the best long-term 
approach.  Apparently the ext3 maintainers do, too, because tytso/sct's 
"ext roadmap" paper publishing a while ago describes extents, too.  (I 
wish I had a URL for that)

Anyway, something to keep in mind:

Changing the underlying disk format without bumping the filesystem 
revision is a hugely bad idea.  I disagreed with merging htree (even 
though its backward compat) without bumping the filesystem version, too.

Vendors, distributors, OEMs, etc. all test against existing on-disk 
formats, when they release their products.  When the filesystem format 
for an existing filesystem, in production, changes underneath them, they 
tend to get worried and annoyed.  So, to all ext developers,

Please add <it> to ext4 not ext3!

	Jeff



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