All of lore.kernel.org
 help / color / mirror / Atom feed
From: Jan Kara <jack@suse.cz>
To: Andreas Dilger <adilger@dilger.ca>
Cc: Jan Kara <jack@suse.cz>, Eric Sandeen <sandeen@redhat.com>,
	Linux FS Devel <linux-fsdevel@vger.kernel.org>,
	ext4 List <linux-ext4@vger.kernel.org>,
	Andrew Morton <akpm@linux-foundation.org>
Subject: Re: [LSF/MM TOPIC] Drop ext2/ext3 codebase? When?
Date: Fri, 11 Feb 2011 12:16:58 +0100	[thread overview]
Message-ID: <20110211111658.GA5187@quack.suse.cz> (raw)
In-Reply-To: <946A4527-3A1C-4EC5-BEAC-4E47F3CFDF01@dilger.ca>

On Mon 07-02-11 08:35:31, Andreas Dilger wrote:
> On 2011-02-07, at 08:19, Jan Kara wrote:
> > On Fri 04-02-11 10:36:21, Andreas Dilger wrote:
> >> The question is whether we need to mimic the runtime behavior or just the
> >> on-disk format?  Apps already need to deal with ext4 and other fs that do
> >> not do ext3 ordered mode.
> > 
> >  Well written apps do, but badly written apps don't and e.g. our distro
> > customers don't always have the choice of the application. So as a developer
> > I see your point (screw stupidly written apps) but in the real world, I'm
> > afraid it's too hard on users.
> 
> We have to remember that this is only for new kernels, and does not
> affect older kernels or existing applications, so such users shouldn't be
> affected.
  Well, customers do upgrade distros and that means they get new kernels
but still they are bound to use the same app from their ISV so I don't
think there won't be users hitting this.

> >> I think the best road forward is to make ext4 the default for ext2 and
> >> ext3 filesystems in newer kernels, and mark ext2 and ext3 obsolete. This
> >> will start to get usage and testing of these other config options. The
> >> ext2 mode is already heavily tested at Google, and don't they also test
> >> noextent mode on updated filesystems, or were all of the filesystems
> >> reformatted with ext4 options?
> > 
> >  Yes, I know you are on relatively radical side ;). My position would be
> > to test ext4 for resonable combinations of options as ext2 driver and if
> > that works, switch ext2 as you describe. Then if it works fine for an year
> > or so, we can talk about ext3 but as James said, ext3 is still widely used
> > so there might be more friction on subtle runtime differences...
> 
> Since most new distros use ext4 by default, the point is kind of moot,
> because those users will get this behaviour in any case.  Relatively few
> users upgrade their kernel on a production system after it is installed,
> except for errata kernels, and I definitely wouldn't expect such a change
> to appear in an errata kernel.
Umm, lot of our customers upgrade even production systems (e.g. SLE10 SP3
-> SLE11 SP1 these days). But still, they keep the old filesystem (they do
not reformat their storage) because they were happy with how it worked. And
yes, they are happy about things that get better but loudly complain about
things that got worse for them.

Of course this does not have a perfect solution (someone will always
complain ;) but putting reasonable effort into making behavior of ext4
in the 'compatibility' mode not too much different from ext3 is IMHO decent
to users.

									Honza
-- 
Jan Kara <jack@suse.cz>
SUSE Labs, CR

  reply	other threads:[~2011-02-11 11:16 UTC|newest]

Thread overview: 28+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2011-02-03 14:40 [LSF/MM TOPIC] Drop ext2/ext3 codebase? When? Jan Kara
2011-02-03 15:08 ` Eric Sandeen
2011-02-03 19:32   ` Michael Rubin
2011-02-03 19:49     ` Eric Sandeen
2011-02-03 21:57       ` Amir Goldstein
2011-02-03 22:00         ` Eric Sandeen
2011-02-04 13:59         ` Jan Kara
2011-02-04  0:04     ` Ted Ts'o
2011-02-04 13:17     ` Jan Kara
2011-02-04 17:03       ` Ric Wheeler
2011-02-04 17:17         ` [Lsf-pc] " James Bottomley
2011-02-05 18:43           ` Trond Myklebust
2011-02-07 17:21           ` Mingming Cao
2011-02-12 11:05       ` Amir Goldstein
2011-02-14 17:25         ` Jan Kara
2011-02-14 19:00           ` Amir Goldstein
2011-02-14 19:58             ` Ted Ts'o
2011-02-14 20:59               ` Andreas Dilger
2011-02-14 21:22               ` Amir Goldstein
2011-02-15  4:28               ` Dave Chinner
2011-02-15 17:29                 ` Ted Ts'o
2011-02-21 23:48                   ` Dave Chinner
2011-02-04 13:03   ` Jan Kara
2011-02-04 17:36     ` Andreas Dilger
2011-02-07 16:19       ` Jan Kara
2011-02-07 16:35         ` Andreas Dilger
2011-02-11 11:16           ` Jan Kara [this message]
2011-02-11 18:44             ` Michael Rubin

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=20110211111658.GA5187@quack.suse.cz \
    --to=jack@suse.cz \
    --cc=adilger@dilger.ca \
    --cc=akpm@linux-foundation.org \
    --cc=linux-ext4@vger.kernel.org \
    --cc=linux-fsdevel@vger.kernel.org \
    --cc=sandeen@redhat.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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.