public inbox for linux-ext4@vger.kernel.org
 help / color / mirror / Atom feed
From: Eric Sandeen <sandeen@redhat.com>
To: Theodore Tso <tytso@MIT.EDU>
Cc: linux-ext4@vger.kernel.org
Subject: Re: [PATCH, RFC] Add new "development flag" to the ext4 filesystem
Date: Tue, 22 Jan 2008 21:55:37 -0600	[thread overview]
Message-ID: <4796BAB9.7000502@redhat.com> (raw)
In-Reply-To: <20080122231707.GA21968@mit.edu>

Theodore Tso wrote:
> As discussed on RFC, this flag is simply a generic "this is a
> crash/burn test filesystem" marker.  If it is set, then filesystem
> code which is "in development" will be allowed to mount the
> filesystem.  Filesystem code which is not considered ready for
> prime-time will check for this flag, and if it is not set, it will
> refuse to touch the filesystem.
> 
> As we start rolling ext4 out to distro's like Fedora, et. al, this
> makes it less likely that a user might accidentally start using ext4
> on a production filesystem; a bad thing, since that will essentially
> make it be unfsckable until e2fsprogs catches up.
> 
> 						- Ted
> 

Overall, seems ok.  One other question though, when ext4 is a
fully-fledged production filesystem, and the flag requirement is gone,
what stops ext3 filesystems from being silently mounted as ext4, just as
happened with ext4dev today?  Will users need to be sure everything
explicitly mounts -t ext3 to avoid this?


+static void parse_extended_opts(ext2_filsys fs, const char *opts)

...

+		if (!strcmp(token, "test_fs")) {
+			fs->super->s_flags |= EXT2_FLAGS_TEST_FILESYS;
+			printf("Setting test filesystem flag\n");
+			ext2fs_mark_super_dirty(fs);
+		} else if (!strcmp(token, "production_fs")) {
+			fs->super->s_flags &= ~EXT2_FLAGS_TEST_FILESYS;
+			printf("Clearing test filesystem flag\n");
+			ext2fs_mark_super_dirty(fs);
+		} else
+			r_usage++;
+	}
+	if (r_usage) {
+		fprintf(stderr, _("\nBad options specified.\n\n"
+			"Extended options are separated by commas, "
+			"and may take an argument which\n"
+			"\tis set off by an equals ('=') sign.\n\n"
+			"Valid extended options are:\n"
+			"\ttestfs\n"));

help text doesn't match reality here, missing a "_"

-Eric

  reply	other threads:[~2008-01-23  3:56 UTC|newest]

Thread overview: 12+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2008-01-22 23:17 [PATCH, RFC] Add new "development flag" to the ext4 filesystem Theodore Tso
2008-01-23  3:55 ` Eric Sandeen [this message]
2008-01-23 16:53   ` Theodore Tso
2008-01-23 17:04     ` Eric Sandeen
2008-01-23 17:26       ` Theodore Tso
2008-01-23 21:50     ` Andreas Dilger
2008-01-25 10:05       ` Jan Kara
2008-01-25 10:50         ` Andreas Dilger
2008-01-28 12:16           ` Jan Kara
2008-01-30 22:26 ` supersud501
2008-01-30 22:48   ` Theodore Tso
2008-01-30 23:03     ` supersud501

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=4796BAB9.7000502@redhat.com \
    --to=sandeen@redhat.com \
    --cc=linux-ext4@vger.kernel.org \
    --cc=tytso@MIT.EDU \
    /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