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
-
To unsubscribe from this list: send the line "unsubscribe linux-ext4" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
