From: Josh Boyer <jwboyer@redhat.com>
To: Andreas Dilger <adilger@dilger.ca>
Cc: Eric Sandeen <sandeen@redhat.com>,
"Theodore Ts'o" <tytso@mit.edu>,
linux-ext4@vger.kernel.org, kernel-team@fedoraproject.org
Subject: Re: [PATCH] ext4: Support "check=none" "nocheck" mount options
Date: Wed, 11 Jan 2012 09:50:07 -0500 [thread overview]
Message-ID: <20120111145004.GA13986@zod.bos.redhat.com> (raw)
In-Reply-To: <7A0721E1-689F-4B9B-BD8C-86A03DDF20CE@dilger.ca>
On Wed, Jan 11, 2012 at 03:07:33AM -0700, Andreas Dilger wrote:
> On 2012-01-10, at 10:43 AM, Eric Sandeen wrote:
> > On 1/10/12 11:41 AM, Josh Boyer wrote:
> >> The ext2/ext3 filesystems supported "check=none" and "nocheck" as mount options
> >> even though that was already the default behavior and it essentially did
> >> nothing. When using ext4 to mount ext2/ext3 filesystems, that mount option
> >> causes the mount to fail. That isn't as backward compatible as it could be,
> >> so add support to ext4 to accept the option.
> >
> > The only thing ext2 does with those options today is to clear the flag,
> > and I can't find anything in userspace or kernelspace which would have set
> > it in any case. It seem dead, but we do need the compatibility in ext4
> > if it's to handle ext2&3 seamlessly, I guess.
>
> At a minimum the use of obsolete options like this should print a warning
> at mount time so that there is some chance the user will notice and remove
> the old option from their config. Otherwise it is impossible to even get
> rid of old useless cruft like this if we need to maintain functionally-useless
> compatibility forever.
I can add a printk(KERN_WARN in the case statement instead of just
having it break. That's not a big deal, but I doubt it's going to get
seen much. I'm very hesitant to add a WARN_ON or anything else that is
going to generate a backtrace because it's just going to be scary
looking and cause more work for distributions that have automated bug
reporting tools.
> Dredging through my memories, I recall that this option used to disable
> the checks done at mount(?) time that compared the bits set in the block
> and inode bitmaps against the summary values in the group descriptors
> (AFAIR). Or maybe it was comparing the group descriptor summary values
> against the superblock values?
Yeah, something like that. It's been the default behavior of ext2/ext3
for a long time now. So long that the "check=normal" and "check=strict"
options (non-default) aren't even supported there anymore.
> In any case, I can't imagine why a user would have this set for a kernel
> option that might have last been valid 10 years ago, and why the 5 users
> in the world that might have this set cannot simply remove it from their
> fstab, since it does absolutely nothing?
This was prompted by a bug report against util-linux, as the man page
still had the option as valid for ext2 (which it is). Since ext4 is
claiming to be directly usable for ext2 filesystems, I don't think it is
unreasonable to mount an fs that has that option set. If it makes
things easier I could wrap all of this in CONFIG_EXT4_USE_FOR_EXT23
ifdefs, but that seemed to make the code unnecessarily uglier.
josh
next prev parent reply other threads:[~2012-01-11 14:50 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
2012-01-10 17:41 [PATCH] ext4: Support "check=none" "nocheck" mount options Josh Boyer
2012-01-10 17:43 ` Eric Sandeen
2012-01-11 10:07 ` Andreas Dilger
2012-01-11 14:50 ` Josh Boyer [this message]
2012-01-11 21:07 ` Andreas Dilger
2012-01-11 15:13 ` Eric Sandeen
2012-01-11 15:26 ` Ted Ts'o
2012-01-11 15:35 ` Eric Sandeen
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=20120111145004.GA13986@zod.bos.redhat.com \
--to=jwboyer@redhat.com \
--cc=adilger@dilger.ca \
--cc=kernel-team@fedoraproject.org \
--cc=linux-ext4@vger.kernel.org \
--cc=sandeen@redhat.com \
--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;
as well as URLs for NNTP newsgroup(s).