handling unrecognised mount options

handling unrecognised mount options

[Andrew Morton]

None of my machines will successfully boot into 2.4 kernels because I have
"commit=30" added to the ext3 mount options in /etc/fstab.

The ext3 driver in those kernels does not to recognise that option and it
fails the mount.

This seems to be a fairly gratuitous and pointless forward-incompatibility.

I propose that henceforth filesystems will, when presented with an
unrecognised mount option, warn and proceed with the mount anyway.

Can anyone see any problems with that?

Re: handling unrecognised mount options

[Andries Brouwer]

On Sun, Mar 16, 2003 at 03:00:03AM -0800, Andrew Morton wrote:

> None of my machines will successfully boot into 2.4 kernels because I have
> "commit=30" added to the ext3 mount options in /etc/fstab.
> 
> The ext3 driver in those kernels does not to recognise that option and it
> fails the mount.
> 
> This seems to be a fairly gratuitous and pointless forward-incompatibility.
> 
> I propose that henceforth filesystems will, when presented with an
> unrecognised mount option, warn and proceed with the mount anyway.
> 
> Can anyone see any problems with that?

I would prefer the conservative approach, doing the mount only
when also some "force" flag is present.

Mounting is a dangerous operation.
An incorrect mount can crash the kernel and can damage the filesystem.

Andries

Re: handling unrecognised mount options

[Randy.Dunlap]

> On Sun, Mar 16, 2003 at 03:00:03AM -0800, Andrew Morton wrote:
>
>> None of my machines will successfully boot into 2.4 kernels because I have
>> "commit=30" added to the ext3 mount options in /etc/fstab.
>>
>> The ext3 driver in those kernels does not to recognise that option and it
>> fails the mount.
>>
>> This seems to be a fairly gratuitous and pointless
>> forward-incompatibility.
>>
>> I propose that henceforth filesystems will, when presented with an
>> unrecognised mount option, warn and proceed with the mount anyway.
>>
>> Can anyone see any problems with that?
>
> I would prefer the conservative approach, doing the mount only
> when also some "force" flag is present.
>
> Mounting is a dangerous operation.
> An incorrect mount can crash the kernel and can damage the filesystem.

or drop into maintenance mode.  Or is that what happens now?
or is that not possible?

~Randy

Re: handling unrecognised mount options

[Andrew Morton]

Andries Brouwer <aebr@win.tue.nl> wrote:
>
> On Sun, Mar 16, 2003 at 03:00:03AM -0800, Andrew Morton wrote:
> 
> > None of my machines will successfully boot into 2.4 kernels because I have
> > "commit=30" added to the ext3 mount options in /etc/fstab.
> > 
> > The ext3 driver in those kernels does not to recognise that option and it
> > fails the mount.
> > 
> > This seems to be a fairly gratuitous and pointless forward-incompatibility.
> > 
> > I propose that henceforth filesystems will, when presented with an
> > unrecognised mount option, warn and proceed with the mount anyway.
> > 
> > Can anyone see any problems with that?
> 
> I would prefer the conservative approach, doing the mount only
> when also some "force" flag is present.
> 
> Mounting is a dangerous operation.
> An incorrect mount can crash the kernel and can damage the filesystem.
> 

The only way we could have a problem here is if someone made a
back-incompatible change to a filesystem format which would cause problems
for older kernels.  And then _required_ that newer kernel be given this mount
option.

I just cannot think of any other scenario in which the current behaviour
makes sense.  And it is objectionable.

Certainly it does not make sense for ext2 and ext3 where we have
compatibility flags for these things.  So I'm at least looking for an
argument aganst changing this behaviour for ext2/3.

Re: handling unrecognised mount options

[Szakacsits Szabolcs]

On Sun, 16 Mar 2003, Andrew Morton wrote:
> The only way we could have a problem here is if someone made a
> back-incompatible change to a filesystem format which would cause
> problems for older kernels.  And then _required_ that newer kernel
> be given this mount option.

Explicitely, yes. Implicitely no when other parts of the system can
rely/depend on a mount option. From security compromise to implicitely
trashed data I can imagine anything. In those cases a warning could be
too late.

Another issue is predictibility. If one gives an option he expects the
driver to behave just like that. Long time convention.

	Szaka

Re: handling unrecognised mount options

[Andrew Morton]

Szakacsits Szabolcs <szaka@sienet.hu> wrote:
>
> Another issue is predictibility. If one gives an option he expects the
> driver to behave just like that. Long time convention.
> 

OK, I'll buy that one.

Now what about the inability to switch between kernels?

Re: handling unrecognised mount options

[Szakacsits Szabolcs]

On Sun, 16 Mar 2003, Andrew Morton wrote:
>
> Now what about the inability to switch between kernels?

1) "force" mount
2) [re]mount with the feature if supported by the kernel

	Szaka



-------------------------------------------------------
This SF.net email is sponsored by:Crypto Challenge is now open! 
Get cracking and register here for some mind boggling fun and 
the chance of winning an Apple iPod:
http://ads.sourceforge.net/cgi-bin/redirect.pl?thaw0031en

Re: handling unrecognised mount options

[Andrew Morton]

Szakacsits Szabolcs <szaka@sienet.hu> wrote:
>
> 
> On Sun, 16 Mar 2003, Andrew Morton wrote:
> >
> > Now what about the inability to switch between kernels?
> 
> 1) "force" mount

By changing initscripts?  That defeats the whole idea.

> 2) [re]mount with the feature if supported by the kernel

Yeah, well.  That's what I'm doing at present in rc.local. It's
pretty lame.

Re: handling unrecognised mount options

[Andries Brouwer]

On Sun, Mar 16, 2003 at 09:32:27PM -0800, Andrew Morton wrote:
> Szakacsits Szabolcs <szaka@sienet.hu> wrote:
> 
> > 2) [re]mount with the feature if supported by the kernel
> 
> Yeah, well.  That's what I'm doing at present in rc.local. It's
> pretty lame.

(i) testing kernel version is often required:

Of course one hopes that initscripts can be independent
of the kernel version. But usually they cannot.

Today 2.4.20 and 2.5.64 number my ethernet cards differently,
so the network scripts have to depend on kernel version.

The use of ipfwadm / ipchains / iptables depends on kernel version.

In the course of time I have seen lp0 and lp1 being interchanged,
the numbering of partitions changed (with BSD slices after all
DOS-type partitions) etc.

(ii) mounting a filesystem may be dangerous for the kernel:

Many filesystem implementations do not check everything read from disk
but just use this data. If the disk filesystem is corrupt, or if the
filesystem was mounted with the wrong type this can cause kernel
corruption.

(iii) mounting a filesystem may be dangerous for the filesystem:

Clearly, if the kernel writes to the filesystem and is mistaken
about its type, the filesystem can be corrupted.

(iv) mount options given help determining filesystem type and semantics

In "mount -t ufs -o ufstype=sunx86" the filesystem type is
determined by an option. Certainly one should not ignore this
option on old kernels where it is not implemented.

In "mount -t vfat -o gid=15" mount permissions are defined.
Certainly one should not ignore this option on old kernels
where it is not implemented.

In "mount -t ext2 -o grpid" semantics for the group ID of
newly created files is defined. Etc.

(v) users are lazy

Of course everybody should always define the filesystem type
when giving a mount command. But people prefer to type as
little as possible, and let mount do the probing.
This means that "mount dev /dir -o errors=remount-ro"
only considers filesystem types where "errors=remount-ro"
is a known option. And "mount dev /dir -o gid=15"
will only consider filesystem types where "gid=15"
is a known option. Ignoring unknown options makes this
dangerous probing a little bit more dangerous.


In your particular situation ignoring this unknown option
may be harmless. But in general it is not.

Andries

Re: handling unrecognised mount options

[Bryan Henderson]

I've never seen this done in string format option specifications, but in
more machine-oriented formats, I often address this requirement by defining
two sets of reserved option flags: ones that are mandatory and ones that
are effectively suggestions.  If the code doesn't recognize one of the
mandatory flags, it has to fail and say, "whatever you're asking for, I
don't know how to do it."  If the code doesn't recognize one of the
suggestion flags, it just ignores it, maybe with a warning.

Something like that could be worked into the syntax of mount options.

The developer can also leave the decision up to the user by adding both
versions of the new option -- one mandatory, and one suggestion.