mirror of https://lore.kernel.org/lkml/
 help / color / mirror / Atom feed
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>
Subject: Re: [Ext2-devel] Re: [RFC] extents,delayed allocation,mballoc for ext3
Date: 19 Apr 2004 20:47:10 +0100	[thread overview]
Message-ID: <1082404030.2237.72.camel@sisko.scot.redhat.com> (raw)
In-Reply-To: <m3llkyojcx.fsf@bzzz.home.net>

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



  reply	other threads:[~2004-04-19 19:47 UTC|newest]

Thread overview: 7+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2004-04-13 19:28 alex
2004-04-14  4:01 ` Matt Mackall
2004-04-14 12:05   ` Alex Tomas
2004-04-19 19:47     ` Stephen C. Tweedie [this message]
2004-04-20 22:05       ` [Ext2-devel] " Matt Mackall
2004-04-14 12:10 ` Alex Tomas
2004-04-14 17:49   ` [Ext2-devel] " Mingming Cao

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=1082404030.2237.72.camel@sisko.scot.redhat.com \
    --to=sct@redhat.com \
    --cc=alex@clusterfs.com \
    --cc=ext2-devel@lists.sourceforge.net \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mpm@selenic.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox

Powered by JetHome