linux-ext4.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Eric Sandeen <sandeen@redhat.com>
To: Andreas Dilger <adilger@dilger.ca>
Cc: Josh Boyer <jwboyer@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:13:40 -0600	[thread overview]
Message-ID: <4F0DA724.2040506@redhat.com> (raw)
In-Reply-To: <7A0721E1-689F-4B9B-BD8C-86A03DDF20CE@dilger.ca>

On 1/11/12 4:07 AM, 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.
> 
> 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?
> 
> 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?

Well, I agree that it should be deprecated, but that's a separate issue from
making ext4 handle all current ext2/3 mount options.

Let's just push this one in, and can do another patch to add the dire
deprecation warnings to all filesystems, ok?  Then in 5 more years we can
remember to remove it ;)

-Eric

>>> ---
>>> fs/ext4/super.c |    7 ++++++-
>>> 1 files changed, 6 insertions(+), 1 deletions(-)
>>>
>>> diff --git a/fs/ext4/super.c b/fs/ext4/super.c
>>> index 3e1329e..5ff09e7 100644
>>> --- a/fs/ext4/super.c
>>> +++ b/fs/ext4/super.c
>>> @@ -1333,7 +1333,7 @@ enum {
>>> 	Opt_nomblk_io_submit, Opt_block_validity, Opt_noblock_validity,
>>> 	Opt_inode_readahead_blks, Opt_journal_ioprio,
>>> 	Opt_dioread_nolock, Opt_dioread_lock,
>>> -	Opt_discard, Opt_nodiscard, Opt_init_itable, Opt_noinit_itable,
>>> +	Opt_discard, Opt_nodiscard, Opt_init_itable, Opt_noinit_itable, Opt_nocheck,
>>> };
>>>
>>> static const match_table_t tokens = {
>>> @@ -1409,6 +1409,8 @@ static const match_table_t tokens = {
>>> 	{Opt_init_itable, "init_itable=%u"},
>>> 	{Opt_init_itable, "init_itable"},
>>> 	{Opt_noinit_itable, "noinit_itable"},
>>> +	{Opt_nocheck, "check=none"},
>>> +	{Opt_nocheck, "nocheck"},
>>> 	{Opt_err, NULL},
>>> };
>>>
>>> @@ -1905,6 +1907,9 @@ set_qf_format:
>>> 		case Opt_noinit_itable:
>>> 			clear_opt(sb, INIT_INODE_TABLE);
>>> 			break;
>>> +		case Opt_nocheck:
>>> +			/* ext2/ext3 used to "support" this option.  Silently eat it */
>>> +			break;
>>> 		default:
>>> 			ext4_msg(sb, KERN_ERR,
>>> 			       "Unrecognized mount option \"%s\" "
>>
>> --
>> To unsubscribe from this list: send the line "unsubscribe linux-ext4" in
>> the body of a message to majordomo@vger.kernel.org
>> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> 
> 
> Cheers, Andreas
> 
> 
> 
> 
> 


  parent reply	other threads:[~2012-01-11 15:13 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
2012-01-11 21:07       ` Andreas Dilger
2012-01-11 15:13     ` Eric Sandeen [this message]
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=4F0DA724.2040506@redhat.com \
    --to=sandeen@redhat.com \
    --cc=adilger@dilger.ca \
    --cc=jwboyer@redhat.com \
    --cc=kernel-team@fedoraproject.org \
    --cc=linux-ext4@vger.kernel.org \
    --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).