[lkml]   [2003]   [Aug]   [11]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
SubjectRe: [RFC] file extents for EXT3
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!


To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to
More majordomo info at
Please read the FAQ at

 \ /
  Last update: 2005-03-22 13:47    [W:0.086 / U:0.108 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site