From: Jan Kara <jack@suse.cz>
To: Andreas Dilger <adilger@dilger.ca>
Cc: Jan Kara <jack@suse.cz>, Eric Sandeen <sandeen@redhat.com>,
"lsf-pc@lists.linuxfoundation.org"
<lsf-pc@lists.linuxfoundation.org>,
"linux-fsdevel@vger.kernel.org" <linux-fsdevel@vger.kernel.org>,
"linux-ext4@vger.kernel.org" <linux-ext4@vger.kernel.org>,
Andrew Morton <akpm@linux-foundation.org>
Subject: Re: [LSF/MM TOPIC] Drop ext2/ext3 codebase? When?
Date: Mon, 7 Feb 2011 17:19:33 +0100 [thread overview]
Message-ID: <20110207161933.GB5337@quack.suse.cz> (raw)
In-Reply-To: <316721F8-70CD-4E29-A94E-BFEF2D762829@dilger.ca>
On Fri 04-02-11 10:36:21, Andreas Dilger wrote:
> On 2011-02-04, at 6:03, Jan Kara <jack@suse.cz> wrote:
> >> I think that ext4 with nodelalloc should mostly mimic ext3 in those
> >> cases, no?
> > Yeah, mostly. The biggest obstacle I see here is the different behavior
> > of mmap - with nodelalloc allocation happens at the time of page fault and
> > that fragments the file like hell for some kinds of load. Since ext3 here
> > essentially does delayed allocation, it might be useful to do delayed
> > allocation only from page fault path when we try to mimic ext3 behavior.
> > So mimicking ext3 is possible but needs some tweaks...
>
> 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.
> >> If we can have a real plan for moving in this direction though, I'd
> >> support it. I'm just not sure how we get enough real testing under
> >> our belts to be comfortable with dropping ext[23], especially as
> >> most distros now default to ext4 anyway.
> > Well, I believe this actually works for us. If the real users move to
> > ext4 (or a different fs), then it's easier to make ext[23] mode in ext4
> > good enough for the few legacy users...
>
> 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...
Honza
--
Jan Kara <jack@suse.cz>
SUSE Labs, CR
next prev parent reply other threads:[~2011-02-07 16:19 UTC|newest]
Thread overview: 22+ 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-04 13:03 ` Jan Kara
2011-02-04 17:36 ` Andreas Dilger
2011-02-07 16:19 ` Jan Kara [this message]
2011-02-07 16:35 ` Andreas Dilger
2011-02-11 11:16 ` Jan Kara
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=20110207161933.GB5337@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=lsf-pc@lists.linuxfoundation.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).