Re: RFC: changing the default NFSv4 minor version?

From: Rodney W. Grimes <freebsd-rwg_at_gndrsh.dnsmgr.net>
Date: Fri, 14 May 2021 06:17:35 -0700 (PDT)
> On Thu, May 13, 2021 at 11:02:35PM +0000, Rick Macklem wrote:
> >Hi,
> >
> >I believe that NFSv4.1 and NFSv4.2 are now mature in freebsd-current/main.
> >I also believe that NFSv4.1/4.2 is a better protocol than NFSv4.0.
> >(In particular, the sessions mechanism for "exactly once RPC semantics"
> > is a significant improvement over the duplicate request cache for NFSv4.0,
> > plus other improvements.)
> >
> >Right now, the FreeBSD NFSv4 client will use NFSv4.0 unless the
> >"minorversion" mount option is used to set the minor version to 1 or 2.
> >
> >The Linux client uses the highest minor version supported by both
> >client and server by default.

If this "Linux client" is expanded to say client and server (which I
suspect is true as I doubt it would work without support from the
server) then I am good with doing this same "fail to highest
supported version silently" in FreeBSD.

> >I'd like to propose that the default behaviour of the FreeBSD client
> >be changed to do the same, so that NFSv4.1/4.2 will be used when possible.
> >--> The "minorversion" mount option could still be used to override the
> >      above default.
> >
> >I have hesitated doing this change because it could be considered a POLA
> >violation, but I think the change from 4.0->4.1/4.2 will normally be a
> >neutral to positive experience. (To be honest, I suspect most won't notice
> >the change.)
> >
> >How do others feel about this change?
> >
> >rick
> >_______________________________________________
> >freebsd-current_at_freebsd.org mailing list
> >https://lists.freebsd.org/mailman/listinfo/freebsd-current
> >To unsubscribe, send any mail to "freebsd-current-unsubscribe_at_freebsd.org
> 
> Hi Rick,
> 
>       If I understand your plans correctly, you're not going to be making
>       it so that minorversion=N complains?

Ah, I think that if you specify a minorversion and the server
does not support that minorversion it SHOULD complain.  Only
if when a minorversion has NOT been specified should it silently
use the highest common version.

> 
>       In that case, I don't quite understand how it can be a POLA
>       violation, since presumably it'll fall back to NFSv4.0 if that's
>       the only thing that's supported by ntpd on some other system.

Ignoring the ntpd typo, I think ricks concern on POLA is that currently
in FreeBSD if you do NOT specify any minor version you get v4.0 and
only v4.0 even if both sides support v4.2, so with his change things
are suddenly going to change, that may astonish some.  

> 
>       At any rate, I'm all for it since I'm already using NFSv4.2. :)

I support this change with the caveats that it only occurs if the
minorversion is unspecified and this same negotiation logic is
applied to both server and client.  (Ie, if I spec a minorversion
on the server it is no longer free to negotiate any other version,
IE if I spec 1 it should *NOT* drop to 0.  It may mean minorversion
becomes minorversions or highestminor?    So that I can make a
server that allows minor={0,1} or even {1,2}, ie I in that second
case I want it to NOT use a minor=0 mount.

> Yours,
> Daniel Ebdrup Jensen
-- 
Rod Grimes                                                 rgrimes_at_freebsd.org
Received on Fri May 14 2021 - 11:17:38 UTC

This archive was generated by hypermail 2.4.0 : Wed May 19 2021 - 11:41:28 UTC