Ext3 users - Dec 2000 - bomb out on unknown rootflags?

Doing some debugging of my kernel build with ext3 and noticed something
interesting.  At the bottom of the rootflags options processing loop
there is a return failure if there was an option that ext3 did not know
about.

Should this be the behaviour?  Would it not be better to ignore options
not recognized?  Surely, some day, some other filesystem is going to
want to use rootflags to have one of it's options passed in which will
be unknown to ext3.  We don't really want ext3 to fail to mount the
filesystem in that case right?  Or is there something about the option
passing that I am missing?

Also there is a bug in passing root_mount_data to read_super() directly.
 It seems that some filesystems (ext3 included!) such as isofs that want
to modify that data by putting a null between option/value pairs
(overwriting the '=').  The problem of course is that if that
option/value pair is for another filesystem type, to be evaluated later,
when it gets to the next filesystem processing option/value pairs it is
no longer a "option=value" but an "option\0value".  Or
again, am I
missing something?

b.



-- 
Mountain View Data, Inc.

Hi,

On Sun, Dec 17, 2000 at 10:24:14AM -0800, Brian J. Murrell
wrote:
> Doing some debugging of my kernel build with ext3 and noticed something
> interesting.  At the bottom of the rootflags options processing loop
> there is a return failure if there was an option that ext3 did not know
> about.
> 
> Should this be the behaviour?  Would it not be better to ignore options
> not recognized?
If the flags are "create a journal on such-and-such-an-inode", then we
definitely want to do nothing if the user has made a typo!
> Surely, some day, some other filesystem is going to
> want to use rootflags to have one of it's options passed in which will
> be unknown to ext3.
Possibly, but if the rootflags are destined for a different filesystem
then we _want_ ext3 to leave the filesystem alone.  

Think about what would happen if we tried ext2 before ext3, for
example, and ext2 decided that it could safely ignore the journaling
rootflags.
> Also there is a bug in passing root_mount_data to read_super() directly.
>  It seems that some filesystems (ext3 included!) such as isofs that want
> to modify that data by putting a null between option/value pairs
> (overwriting the '=').  The problem of course is that if that
> option/value pair is for another filesystem type, to be evaluated later,
> when it gets to the next filesystem processing option/value pairs it is
> no longer a "option=value" but an "option\0value".  Or
again, am I
> missing something?
Hmm.  I might fix that, but I'm more likely to remove rootflags
altogether.  Rootflags was really mostly a hack to allow creation of
journals on a root filesystem, in the absence of proper user-mode
tools for setting up ext3 filesystems.  Once the new mkjournal.c code
is integrated into tune2fs, then that will become the preferred way of
setting ext3 parameters on the root filesystem.  At that point I'd
want to drop rootflags in the interest of minimising the impact of
ext3 on the surrounding VFS.

Cheers,
 Stephen