From: Theodore Tso <tytso@MIT.EDU>
To: Andreas Dilger <adilger@sun.com>
Cc: Eric Sandeen <sandeen@redhat.com>, linux-ext4@vger.kernel.org
Subject: Re: [E2FSPROGS, RFC] New mke2fs types parsing
Date: Thu, 21 Feb 2008 08:35:54 -0500 [thread overview]
Message-ID: <20080221133554.GD14614@mit.edu> (raw)
In-Reply-To: <20080221085221.GV3029@webber.adilger.int>
On Thu, Feb 21, 2008 at 01:52:21AM -0700, Andreas Dilger wrote:
> On Feb 20, 2008 17:20 -0500, Theodore Ts'o wrote:
> > There are only three things which mke2fs will do, in my design:
>
> This should all go into the mke2fs man page...
It will be documented; as I said, this was a request for comments
about the overall design, before I finish polishing it and adding man
page documentation, etc. The patch was very much an interim patch,
including lots and lots of debugging printf's. :-)
>
> > [fs_types]
> > ext3 = {
> > features = has_journal
> > }
> > ext4 = {
> > features = extents,flex_bg
> > inode_size = 256
> > }
>
> Presumably the ext4 feature should also have features = has_journal?
> If this is the default for ext4, why would it need to be given for ext3?
>
> We should also add "dir_nlink,flexbg" while we are in there.
Yes, of course. This was an example, not what I plan to check in.
(And it's flex_bg, not flexbg; we also need to add the uninit_groups
flags, etc.)
The other thing which I've been considering is some what to make the
feature list displayed by dumpe2fs a bit easier to understand. One
thought is to bundle a number of features into things like std_ext2,
std_ext3, std_ext4, etc., with an option to display the full set for
someone who wants a more verbose/explicit description. The one caveat
here is that once a bundle is defined, we don't ever want to change it
so that when someone e-mail's a dumpe2fs output as part of a bug
report, there is no question about what a feature bundle means; it
can't be e2fsprogs version dependent.
- Ted
next prev parent reply other threads:[~2008-02-21 13:36 UTC|newest]
Thread overview: 18+ messages / expand[flat|nested] mbox.gz Atom feed top
2008-02-20 14:06 [E2FSPROGS, RFC] New mke2fs types parsing Theodore Ts'o
2008-02-20 18:51 ` Eric Sandeen
2008-02-20 22:20 ` Theodore Tso
2008-02-20 22:28 ` Eric Sandeen
2008-02-21 8:52 ` Andreas Dilger
2008-02-21 13:35 ` Theodore Tso [this message]
2008-03-17 21:29 ` Eric Sandeen
2008-03-18 2:20 ` Theodore Tso
2008-03-18 3:23 ` Eric Sandeen
2008-03-18 4:23 ` Theodore Tso
2008-03-18 5:16 ` Eric Sandeen
2008-03-18 11:01 ` Theodore Tso
2008-03-18 13:11 ` Eric Sandeen
2008-03-18 13:52 ` Theodore Tso
2008-03-18 16:06 ` Eric Sandeen
2008-03-20 19:17 ` Eric Sandeen
2008-03-20 20:49 ` Theodore Tso
2008-03-19 3:36 ` Andreas Dilger
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=20080221133554.GD14614@mit.edu \
--to=tytso@mit.edu \
--cc=adilger@sun.com \
--cc=linux-ext4@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.