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

[Matt Mackall]

On Mon, Apr 19, 2004 at 08:47:10PM +0100, Stephen C. Tweedie wrote:
> Hi,
> 
> On Wed, 2004-04-14 at 13:05, Alex Tomas wrote:
> 
> >  MM> I'm going to assume that there's no way for ext3 without extents
> >  MM> support to mount such a filesystem, so I think this means changing the
> >  MM> FS name. Is there a simple migration path to extents for existing filesystems?
> > 
> > yeah. you're right. I see no way to make it backward-compatible. in fact,
> > I haven't think much about name. probably you're right again and this
> > "ext3 on steroids" should have another name.
> 
> We've already got feature compatibility bits that can deal with this
> sort of thing.  There are various other proposed incompatible features,
> such as large inodes and dynamically placed metadata (eg. placing inode
> tables into an inode "file"), too.  Rather than invent new names for
> each combination of incompatible feature set, we're probably better off
> just using the feature masks.

I'm aware of the existence of such features, I just think it's yet to
be demonstrated that they're actually a good idea for real deployment
by themselves. ext3+{btree,extents} is not backwards compatible in any
useful sense, unlike features such as journalling, directory hashing,
sparse superblocks, wandering journals, etc. Given that you can't
mount the new filesystem with an old kernel, not changing the name can
only result in confusion.

But I see your point about dealing with a cartesian product of
features. So if and when this stuff approaches beta, we should
probably use the feature flags _and_ change the name to something like
ext3+be (btrees, extents) or ext3+i (inode in file) to indicate the
presence of experimental, incompatible features, and when the feature
set is actually pinned down, rename it simply ext3+ or ext4 or whatever.

It might be possible to have ext4 actually be a family of filesystems
where extents or large inodes are optional, but I suspect the value of
that would be minimal and again, all such features would have to be
available in every kernel tree that claimed to support ext4.

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