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>,
	"steved@redhat.com" <steved@redhat.com>,
	"linux-nfs@vger.kernel.org" <linux-nfs@vger.kernel.org>
Subject: Re: [PATCH 2/2] nfsd: Change the default to enable all minor versions unless told otherwise
Date: Fri, 24 Feb 2017 15:32:32 -0500	[thread overview]
Message-ID: <20170224203232.GC26378@fieldses.org> (raw)
In-Reply-To: <87fuj4qq4y.fsf@notabene.neil.brown.name>

On Fri, Feb 24, 2017 at 01:27:57PM +1100, NeilBrown wrote:
> On Fri, Feb 24 2017, Trond Myklebust wrote:
> 
> > Hi Neil,
> >
> > On Fri, 2017-02-24 at 12:17 +1100, NeilBrown wrote:
> >> On Thu, Feb 23 2017, Trond Myklebust wrote:
> >> 
> >> > Instead of letting the kernel decide, default to enabling all
> >> > versions,
> >> > and let the user be more specifc in /etc/nfs.conf or on the command
> >> > line.
> >> 
> >> What is your rationale for this?
> >> I think there is value in allowing the kernel to support a version
> >> while
> >> disabling it by default.  This allows it to be used for
> >> experimentation,
> >> without much risk of it being used in production until it is deemed
> >> to
> >> be really ready.
> >
> > I think we can still do that by having the kernel simply not report
> > that version. You'll note that -V4.x and -N4.x are allowed whether or
> > not the kernel is reporting a version 'x' in /proc/fs/nfsd/versions.
> >
> > IOW: if you want to make the version not appear by default because it
> > is unstable, then you probably don't want it to appear when the user
> > does '+V4' either so you might as well hide it in
> > /proc/fs/nfsd/versions too.
> 
> That seems reasonable - possibly even better than the current approach,
> though it is hard to be sure without actually trying it out for a while.
> I haven't poured over the patches enough for a reviewed-by, but
>   Acked-by: NeilBrown <neilb@suse.com>

It's too late to tell old kernels to hide experimental versions, though.
And it's 4.1's experimental stage that's most likely to be a
problem--though maybe that's getting long enough go that not too many
people are bisecting back to that era of kernel.

I dunno, I'm inclined to drop as long as this part isn't necessary to
solve Trond's immediate problem.

--b.

  reply	other threads:[~2017-02-24 20:32 UTC|newest]

Thread overview: 13+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2017-02-24  0:33 [PATCH 0/2] Patch rpc.nfsd to allow the caller to turn off NFSv4.0 Trond Myklebust
2017-02-24  0:33 ` [PATCH 1/2] nfsd: Allow the caller to turn off NFSv4.0 without turning off NFSv4.x Trond Myklebust
2017-02-24  0:33   ` [PATCH 2/2] nfsd: Change the default to enable all minor versions unless told otherwise Trond Myklebust
2017-02-24  1:17     ` NeilBrown
2017-02-24  1:42       ` Trond Myklebust
2017-02-24  2:27         ` NeilBrown
2017-02-24 20:32           ` bfields [this message]
2017-04-04 20:08     ` Steve Dickson
2017-04-04 20:07   ` [PATCH 1/2] nfsd: Allow the caller to turn off NFSv4.0 without turning off NFSv4.x Steve Dickson
2017-04-04 20:26     ` Trond Myklebust
2017-04-04 21:07       ` Steve Dickson
     [not found]         ` <4B984CF4-7D50-4B11-B26E-886845068329@primarydata.com>
2017-04-04 21:31           ` Steve Dickson
2017-04-05 17:29             ` Steve Dickson

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=20170224203232.GC26378@fieldses.org \
    --to=bfields@fieldses.org \
    --cc=linux-nfs@vger.kernel.org \
    --cc=neilb@suse.com \
    --cc=steved@redhat.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.