From: Peter Staubach <staubach@redhat.com>
To: chuck.lever@oracle.com
Cc: trond.myklebust@netapp.com, linux-nfs@vger.kernel.org
Subject: Re: [PATCH] NFS: Only warn on unrecognized mount options
Date: Fri, 11 Apr 2008 16:23:11 -0400 [thread overview]
Message-ID: <47FFC8AF.8020009@redhat.com> (raw)
In-Reply-To: <47FFC669.80702@oracle.com>
Chuck Lever wrote:
> Peter Staubach wrote:
>> Chuck Lever wrote:
>>> To provide compatibility with automounters who use a common set of
>>> mount
>>> options for all file systems, change the NFS in-kernel mount option
>>> parser
>>> to ignore mount options it doesn't recognize.
>>>
>>> Signed-off-by: Chuck Lever <chuck.lever@oracle.com>
>>> ---
>>> Yet another NFS mount patch! Build tested only. Comments?
>>>
>>> fs/nfs/super.c | 7 ++-----
>>> 1 files changed, 2 insertions(+), 5 deletions(-)
>>>
>>> diff --git a/fs/nfs/super.c b/fs/nfs/super.c
>>> index f921902..a7201f0 100644
>>> --- a/fs/nfs/super.c
>>> +++ b/fs/nfs/super.c
>>> @@ -1044,7 +1044,8 @@ static int nfs_parse_mount_options(char *raw,
>>> break;
>>>
>>> default:
>>> - goto out_unknown;
>>> + printk(KERN_INFO "NFS: unrecognized mount option '%s'"
>>> + " ignored\n", p);
>>> }
>>> }
>>>
>>> @@ -1070,10 +1071,6 @@ out_unrec_xprt:
>>> out_unrec_sec:
>>> printk(KERN_INFO "NFS: unrecognized security flavor\n");
>>> return 0;
>>> -
>>> -out_unknown:
>>> - printk(KERN_INFO "NFS: unknown mount option: %s\n", p);
>>> - return 0;
>>> }
>>>
>>> /*
>>
>> This will potentially cause a very large number of messages to be
>> printed in a valid deployment. Do we really need the message?
>
> I was wondering about that.
>
> I left it in because it's useful to know when a valid mount option is
> misspelled. In that case it might cause an important option (such as
> "noac") to be ignored.
There do seem to be valid uses for the message. However, it
could also end up being a bad thing.
Perhaps we could just gather the unknown options and lump
them together in something that would be visible via /proc/mounts
or some such. Something like "unknown=..." in the options list.
ps
next prev parent reply other threads:[~2008-04-11 20:23 UTC|newest]
Thread overview: 9+ messages / expand[flat|nested] mbox.gz Atom feed top
2008-04-11 20:03 [PATCH] NFS: Only warn on unrecognized mount options Chuck Lever
[not found] ` <20080411200249.28007.12509.stgit-meopP2rzCrTwdl/1UfZZQIVfYA8g3rJ/@public.gmane.org>
2008-04-11 20:07 ` Peter Staubach
2008-04-11 20:13 ` Chuck Lever
2008-04-11 20:23 ` Peter Staubach [this message]
2008-04-11 20:24 ` Trond Myklebust
[not found] ` <1207945499.15646.11.camel-rJ7iovZKK19ZJLDQqaL3InhyD016LWXt@public.gmane.org>
2008-04-14 14:00 ` Chuck Lever
2008-04-14 17:19 ` Peter Staubach
-- strict thread matches above, loose matches on Subject: below --
2008-04-11 20:28 Chuck Lever
[not found] ` <20080411202800.31268.3495.stgit-meopP2rzCrTwdl/1UfZZQIVfYA8g3rJ/@public.gmane.org>
2008-04-25 11:33 ` Jeff Layton
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=47FFC8AF.8020009@redhat.com \
--to=staubach@redhat.com \
--cc=chuck.lever@oracle.com \
--cc=linux-nfs@vger.kernel.org \
--cc=trond.myklebust@netapp.com \
/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