From: Steve Dickson <SteveD@RedHat.com>
To: NeilBrown <neilb@suse.de>
Cc: Justin Mitchell <jumitche@redhat.com>,
Benjamin Coddington <bcodding@redhat.com>,
linux-nfs@vger.kernel.org
Subject: Re: [PATCH 0/7 nfs-utils] Assorted improvements to handling nfsmount.conf
Date: Thu, 17 Dec 2020 10:11:02 -0500 [thread overview]
Message-ID: <5c3e7332-b8f1-3cd7-2a38-e003688aa1e8@RedHat.com> (raw)
In-Reply-To: <160809318571.7232.10427700322834760606.stgit@noble>
On 12/15/20 11:43 PM, NeilBrown wrote:
> The handling of version specifiers in mount.nfs, and even in the kernel,
> is somewhat ideosyncratic when multiple versions are listed.
>
> For example, "-o vers=4.1,nfsvers=3" will result in both versions being
> passed to the kernel, and the kernel complaining because version 3
> doesn't support minor version numbers.
> Conversly, "-o nfsvers=4.1,vers=3" will result in the "nfsvers=4.1"
> being stripped off and vers=3 being used.
>
> Further, version settings found in /etc/nfsmount.conf are sometimes
> ignored if a version is given on the command line, and sometimes not.
> If "nfsvers=3" is in the config file, then the presense of "-o vers=4.1"
> will cause it to be ignored, the presense of "-o nfsvers=4.1" will too, but
> mainly because of sloppy code. However "-o v4.1" won't cause the config
> file setting to be ignored.
>
> This series cleans up all of this and some related issues, and updates
> the man page.
>
> With other options, the last option listed on the command line wins.
> I have not tried to provide that for version options. Instead, if there
> are multiple version options listed, and error is reported.
>
> Thanks,
> NeilBrown
The series is Committed! (tag: nfs-utils-2-5-3-rc3)
steved.
>
> ---
>
> NeilBrown (7):
> mount: configfile: remove whitesspace from end of lines
> mount: report error if multiple version specifiers are given.
> Revert "mount.nfs: merge in vers= and nfsvers= options"
> mount: convert configfile.c to use parse_opt.c
> mount: options in config file shouldn't over-ride command-line options.
> mount: don't add config-file protcol version options when already present.
> mount: update nfsmount.conf man page
>
>
> utils/mount/configfile.c | 230 +++++++++++-----------------------
> utils/mount/network.c | 36 +++---
> utils/mount/nfsmount.conf.man | 110 ++++++++++------
> utils/mount/parse_opt.c | 12 +-
> utils/mount/parse_opt.h | 3 +-
> 5 files changed, 174 insertions(+), 217 deletions(-)
>
> --
> Signature
>
prev parent reply other threads:[~2020-12-17 15:11 UTC|newest]
Thread overview: 9+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-12-16 4:43 [PATCH 0/7 nfs-utils] Assorted improvements to handling nfsmount.conf NeilBrown
2020-12-16 4:43 ` [PATCH 4/7] mount: convert configfile.c to use parse_opt.c NeilBrown
2020-12-16 4:43 ` [PATCH 5/7] mount: options in config file shouldn't over-ride command-line options NeilBrown
2020-12-16 4:43 ` [PATCH 2/7] mount: report error if multiple version specifiers are given NeilBrown
2020-12-16 4:43 ` [PATCH 7/7] mount: update nfsmount.conf man page NeilBrown
2020-12-16 4:43 ` [PATCH 1/7] mount: configfile: remove whitesspace from end of lines NeilBrown
2020-12-16 4:43 ` [PATCH 6/7] mount: don't add config-file protcol version options when already present NeilBrown
2020-12-16 4:43 ` [PATCH 3/7] Revert "mount.nfs: merge in vers= and nfsvers= options" NeilBrown
2020-12-17 15:11 ` Steve Dickson [this message]
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=5c3e7332-b8f1-3cd7-2a38-e003688aa1e8@RedHat.com \
--to=steved@redhat.com \
--cc=bcodding@redhat.com \
--cc=jumitche@redhat.com \
--cc=linux-nfs@vger.kernel.org \
--cc=neilb@suse.de \
/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