From: Ted Ts'o <tytso@mit.edu>
To: Michael Rubin <mrubin@google.com>
Cc: Eric Sandeen <sandeen@redhat.com>, Jan Kara <jack@suse.cz>,
lsf-pc@lists.linuxfoundation.org, linux-fsdevel@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: Thu, 3 Feb 2011 19:04:31 -0500 [thread overview]
Message-ID: <20110204000431.GB2623@thunk.org> (raw)
In-Reply-To: <AANLkTi=YxSpgm9vYHBKdASpLOaY_U3=ggsE8yTg_G0Bc@mail.gmail.com>
On Thu, Feb 03, 2011 at 11:32:01AM -0800, Michael Rubin wrote:
> On Thu, Feb 3, 2011 at 7:08 AM, Eric Sandeen <sandeen@redhat.com> wrote:
> > 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.
>
> Eric what sort of testing are you looking for?
The biggest problem in my opinion is that we have a large set of
options, and we don't necessarily test all of them. The options that
I normaly test is
* 4k blocksize, with journal, extents
* 1k blocksize, with journal, extents (this helps flush out problems
that show up architectures with 16k page size and
4k block sizes, i.e., Power PC and Itanium)
* 4k blocksize, no journal
Things that I should also test, but which take a lot longer:
* nodelalloc (and combinatorics, 4k/1k blocksize, journal)
* filesystem with extents disabled (with more combinatorics!)
I'll sometimes do these additional tests, but they're not part of my
regular test sets.
- Ted
--
To unsubscribe from this list: send the line "unsubscribe linux-ext4" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
next prev parent reply other threads:[~2011-02-04 0:04 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 [this message]
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
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=20110204000431.GB2623@thunk.org \
--to=tytso@mit.edu \
--cc=akpm@linux-foundation.org \
--cc=jack@suse.cz \
--cc=linux-ext4@vger.kernel.org \
--cc=linux-fsdevel@vger.kernel.org \
--cc=lsf-pc@lists.linuxfoundation.org \
--cc=mrubin@google.com \
--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.