Linux filesystem development
 help / color / mirror / Atom feed
From: Andrew Morton <akpm@digeo.com>
To: Andries Brouwer <aebr@win.tue.nl>
Cc: linux-fsdevel@vger.kernel.org, ext2-devel@lists.sourceforge.net
Subject: Re: handling unrecognised mount options
Date: Sun, 16 Mar 2003 14:46:24 -0800	[thread overview]
Message-ID: <20030316144624.69060b84.akpm@digeo.com> (raw)
In-Reply-To: <20030316115026.GA7674@win.tue.nl>

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.

  parent reply	other threads:[~2003-03-16 22:46 UTC|newest]

Thread overview: 10+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2003-03-16 11:00 handling unrecognised mount options Andrew Morton
2003-03-16 11:50 ` Andries Brouwer
2003-03-16 19:04   ` Randy.Dunlap
2003-03-16 22:46   ` Andrew Morton [this message]
2003-03-17  4:25     ` Szakacsits Szabolcs
2003-03-17  4:34       ` Andrew Morton
2003-03-17  5:23         ` Szakacsits Szabolcs
2003-03-17  5:32           ` Andrew Morton
2003-03-17  9:18             ` Andries Brouwer
2003-03-17 16:54               ` Bryan Henderson

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=20030316144624.69060b84.akpm@digeo.com \
    --to=akpm@digeo.com \
    --cc=aebr@win.tue.nl \
    --cc=ext2-devel@lists.sourceforge.net \
    --cc=linux-fsdevel@vger.kernel.org \
    /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