Subject: Re: [Ext2-devel] Re: [RFC] extents,delayed allocation,mballoc for
	ext3
From: "Stephen C. Tweedie" <sct@redhat.com>
To: Alex Tomas <alex@clusterfs.com>
Cc: Matt Mackall <mpm@selenic.com>,
       "ext2-devel@lists.sourceforge.net" <ext2-devel@lists.sourceforge.net>,
       linux-kernel <linux-kernel@vger.kernel.org>,
       Stephen Tweedie <sct@redhat.com>
In-Reply-To: <m3llkyojcx.fsf@bzzz.home.net>
References: <m365c3pthi.fsf@bzzz.home.net> <20040414040101.GO1175@waste.org>
	 <m3llkyojcx.fsf@bzzz.home.net>
Content-Type: text/plain
Organization: 
Message-Id: <1082404030.2237.72.camel@sisko.scot.redhat.com>
Mime-Version: 1.0
Date: 19 Apr 2004 20:47:10 +0100
Content-Transfer-Encoding: 7bit
Sender: linux-kernel-owner@vger.kernel.org
Content-Length: 1136
Lines: 28

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.

Cheers,
 Stephen


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