linux-nfs.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: "bfields@fieldses.org" <bfields@fieldses.org>
To: Trond Myklebust <trondmy@primarydata.com>
Cc: "neilb@suse.com" <neilb@suse.com>,
	"linux-nfs@vger.kernel.org" <linux-nfs@vger.kernel.org>
Subject: Re: [PATCH v2 0/2] Fix up nfsd to enable NFSv4.x without NFSv4.0
Date: Mon, 27 Feb 2017 18:03:57 -0500	[thread overview]
Message-ID: <20170227230357.GA11912@fieldses.org> (raw)
In-Reply-To: <1487811610.4863.10.camel@primarydata.com>

On Thu, Feb 23, 2017 at 01:00:12AM +0000, Trond Myklebust wrote:
> On Thu, 2017-02-23 at 11:13 +1100, NeilBrown wrote:
> > On Wed, Feb 22 2017, Trond Myklebust wrote:
> > 
> > > This patch series was intended as a standalone series. However it
> > > now
> > > aims to fix up a few issues with Neil's initial patch:
> > > 
> > > 1) When the user turns off all minor versions of NFSv4, then that
> > > should
> > >    be equivalent to turning off NFSv4 support, and so when someone
> > > tries
> > >    to mount, we should return RPC_PROG_MISMATCH.
> > > 2) Allow the user to use either '4.0' or '4' in order to enable or
> > > disable
> > >    minor version 0. Other minor versions remain enabled/disabled
> > > using the
> > >    '4.x' format.
> > 
> > If I understand you and the code correctly, then this change means
> > that
> > if I run
> > 
> >    rpc.nfsd -N 4
> > 
> > the nfs server will continue to server v4.1 and v4.2 requests, only
> > v4.0
> > will be disabled (Assuming a kernel which defaults to serving v4.0,
> > v4.1
> > and v4.0).
> 
> Unfortunately not... The problem is that rpc.nfsd has a borken parser
> that refuses the '-N4 -V4.2' syntax, and that throws hissy fit if you
> try to feed it '-N4.0' or '-V4.0'.
> 
> The kernel change needs to be accompanied by a fix to nfs-utils.
> 
> > Is that really what we want?
> > 
> > The text in the man page for rpc.nfsd could be read as allowing this
> > interpretation, though it isn't explicit.
> > I've always used "NFSv4" to mean any or all for 4.0, 4.1, 4.2, ...
> 
> We _could_ do that. As I said, that's a question of fixing rpc.nfsd.
> 
> The question here, though, is what should the kernel do when you start
> poking into /proc/fs/nfsd/versions. I think adding a new field between
> '4' and '4.0' might be more disruptive than changing the meaning of '4'
> to mean '4.0' as there might be other parsers of that pseudofile out
> there today.

I'm OK with that, unless Neil sees a problem.

The changelog on the first patch doesn't seem to describe the v2 version
very well; using the below cribbed from your cover letter instead.

    nfsd: fix configuration of supported minor versions
    
    When the user turns off all minor versions of NFSv4, that should be
    equivalent to turning off NFSv4 support, so a mount attempt using NFSv4
    should get RPC_PROG_MISMATCH, not NFSERR_MINOR_VERS_MISMATCH.
    
    Allow the user to use either '4.0' or '4' to enable or disable minor
    version 0.  Other minor versions are still enabled or disabled using the
    '4.x' format.

--b.

  reply	other threads:[~2017-02-28  0:57 UTC|newest]

Thread overview: 10+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2017-02-22 23:35 [PATCH v2 0/2] Fix up nfsd to enable NFSv4.x without NFSv4.0 Trond Myklebust
2017-02-22 23:35 ` [PATCH v2 1/2] nfsd: Allow enabling NFSv4.x without also requiring NFSv4.0 Trond Myklebust
2017-02-22 23:35   ` [PATCH v2 2/2] nfsd: Fix display of the version string Trond Myklebust
2017-02-23  0:13 ` [PATCH v2 0/2] Fix up nfsd to enable NFSv4.x without NFSv4.0 NeilBrown
2017-02-23  1:00   ` Trond Myklebust
2017-02-27 23:03     ` bfields [this message]
2017-03-02 22:57       ` NeilBrown
2017-03-04 18:55         ` Trond Myklebust
2017-03-06  4:26           ` NeilBrown
2017-03-09 20:51             ` bfields

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=20170227230357.GA11912@fieldses.org \
    --to=bfields@fieldses.org \
    --cc=linux-nfs@vger.kernel.org \
    --cc=neilb@suse.com \
    --cc=trondmy@primarydata.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;
as well as URLs for NNTP newsgroup(s).