Re: [PATCH 03/15] Add /etc/nfs.conf support to rpc.nfsd

[NeilBrown <neilb@suse.com>]

[-- Attachment #1: Type: text/plain, Size: 3257 bytes --]

On Thu, Dec 08 2016, "J. Bruce Fields" <bfields@redhat.com> wrote:

> On Wed, Dec 07, 2016 at 09:44:25AM -0500, Steve Dickson wrote:
>> > 
>> > I do wonder if this is ever valid though.  Why do we allow minor
>> > versions to be enabled/disabled?
>> IDK... I think Trond did this... you know...
>> when in doubt... blame Trond! 8-) 
>
> Or Benny, 8daf220a6a83 "nfsd41: control nfsv4.1 svc via
> /proc/fs/nfsd/versions".
>
>> > Does it make any sense to enable a non-contiguous set of minor versions?
>> I don't think so... Talk about handing people rope! ;-)
>
> I can't think of a reason either.
>
>> > Should we just have a maximum NFSv4 minor version?
>> Maybe.. 
>
> If you do that then I'd allow a minimum too.

Why?  I'm trying to understand why you would ever want to turn disable a
particular minor version.  I could equally well ask myself "why specify
a maximum"...

Benny's patch only suggests that it removes the need for
CONFIG_NFSD_V4_1, but why was that needed?
Maybe it is just to disable buggy code if some version is found to have
an inconvenient bug?  The client, by default, tries 4.2, then 4.1, then
4.0.  Older clients might start elsewhere.  So just disabling unreliable
versions individually does seem to make sense.

I note that Benny's original patch disabled v4.1 by default, and
required it to be explicitly enabled.  The current kernel enables all by
default, and requires them be explicitly disabled is required.
My current nfs.conf code will disabled unwanted minor versions, but not
enable any that are already disabled ... I guess I could fix that.

.... it is a shame that we can only enable/disable minor versions
when there are no nfsd threads running.  The justification for
failing if nfsd is active is fairly lame, and only applies
to major versions.  If minor versions could be changed at any time,
then it could be a simple function of rpc.nfsd, and the config
file would never need to enable things, only disable them.

Is there any other reason to disable minor versions, other than to avoid
buggy code (either in server or client)??


Actually.... I have a related question that I keep meaning to ask, but
haven't.

What are the circumstances where NFSv3 should be preferred over NFSv4
(assuming up-to-date kernels on server and client)?

I can think of:
 - NFSv3 is safer if you might need to support loop-back mounts
   as I don't think NFSv4 state management can reliably make forward
   progress against memory pressure.  In particular, creating the
   state-manager thread can deadlock waiting for an NFS write.

 - If you want fast-failover from one server to another,
   NFSv3 is probably faster as it only imposes the grace-time on
   lock requests.  NFSv4 imposes it on OPEN and so READ/WRITE
   as well.

 - NFSv3 is preferred if (for some weird reason) you need
   to use UDP.

Are there any others?  Are there any similar reasons to prefer a smaller
NFSv4 minor version over a larger one?

Thanks,
NeilBrown

>
> --b.
>
>> > I was trying to duplicate the current functionality as closely as
>> > convenient.  That might not be best in this case.
>> You did a good job... this is definitely a nit.
>> 
>> steved.
>> 

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 832 bytes --]