All of lore.kernel.org
 help / color / mirror / Atom feed
From: "bfields@fieldses.org" <bfields@fieldses.org>
To: NeilBrown <neilb@suse.com>
Cc: Trond Myklebust <trondmy@primarydata.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: Thu, 9 Mar 2017 15:51:52 -0500	[thread overview]
Message-ID: <20170309205152.GG3929@fieldses.org> (raw)
In-Reply-To: <87o9xfjain.fsf@notabene.neil.brown.name>

Sorry for not paying close attention here.  Catching up:

On Mon, Mar 06, 2017 at 03:26:40PM +1100, NeilBrown wrote:
> On Sat, Mar 04 2017, Trond Myklebust wrote:
> 
> > The main issue that worried me was one of predictability. What is
> > supposed to happen when you type "echo +4"? One thing that I considered
> > to be a regression, was that previously, I could expect that "echo +4"
> > would at the very least turn on NFSv4 minor version 0, but with the
> > change to semantics, it would only do so if nobody had typed "echo
> > -4.0".
> 
> I don't think I would consider this as a regression. Prior to
> 
> Commit: e35659f1b03c ("NFSD: correctly range-check v4.x minor version when setting versions.")
> 
> "echo -4.0" would result in an error.  After that patch it will result in
> behaviour that you think is inconsistent.  While that might be a poor
> design choice, I don't think it is a regression because it is not
> (holistically) something that worked before and now works differently.
>
> I agree that "echo +4" should do something sensible and predictable.  I
> would like to suggest that it should enable all "supported" NFSv4.x minor
> versions.  That is consistent with how rpc.nfsd uses it, and makes sense
> to me. "echo -4" should disable all minor versions.
> 
> >
> > An analogy would be putting 2 light switches in front of a light bulb,
> > so that unless both switches are on, the bulb will not turn on.
> > Actually, it is worse than that, because none of the bulbs turn on
> > until you start up knfsd (so you can argue that there is a third switch
> > in front of the other two).
> > Why do we need this many levels of switches in a kernel interface? You
> > should be able to achieve the same functionality by just turning on and
> > off the individual minor versions. The right place for designing more
> > complex interfaces would be userspace, and is exactly what the rpc.nfsd
> > utility should be taking care of.
> 
> The "no regressions" rule can often lead to clunky interfaces.  It
> certainly isn't ideal, but sometimes we need to live with it.
> The right place to hide that clunkiness is in rpc.nfsd :-)

That sounds right to me.

> > Finally, there is the issue that the interface allowed situations where
> > knfsd was advertising support for NFSv4 via rpcbind, but there were no
> > minor versions enabled, and so you'd just get a confusing series of
> > NFS4ERR_MINOR_VERSION_MISMATCH replies when attempting to mount. Why
> > even advertise support in that case?
> 
> I agree with this.
> If all minor versions are disabled, the major version should be disabled
> as well.  If any minor versions are enabled, the major version must be
> enabled too.

So, if you have a patch that keeps the agreed-on change while reverting
to a (clunkier, but more backwards-compatible) interface, and if you can
do it while we're still early in 4.11, then I'd take that.

--b.

      reply	other threads:[~2017-03-09 20:52 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
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 [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=20170309205152.GG3929@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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.