Re: RFC: changing the default NFSv4 minor version?
> Rodney W. Grimes wrote:
> [stuff snipped]
> >Daniel Ebdrup Jensen wrote:
> >> 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.
> Yes. The mount attempt currently fails with "minor version not supported"
> when the minor version is not supported by the server.
> My plan would not change this when "minorversion=N" is specified.
>
> > Only
> >if when a minorversion has NOT been specified should it silently
> >use the highest common version.
> Yes, that's my plan.
>
> >>
> >> 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.
> Yes.
>
> >>
> >> 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.
> The server end is passive. It either supports the minor version specified
> in the RPC by the client and performs the RPC or it replies
> NFS4ERR_MINOR_VERSION_MISMATCH if it does not support it.
> The FreeBSD server already has sysctls:
> vfs.nfsd.server_min_minorversion4
> vfs.nfsd.server_max_minorversion4
> that allows a sysadmin to limit the minor versions supported.
>
> I think this satisfies your server requirement?
Yes, it certainly does.
> rick
> > Yours,
> > Daniel Ebdrup Jensen
> Rod Grimes rgri...@freebsd.org
--
Rod Grimes rgri...@freebsd.org
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: RFC: changing the default NFSv4 minor version?
Rodney W. Grimes wrote:
[stuff snipped]
>Daniel Ebdrup Jensen wrote:
>> 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.
Yes. The mount attempt currently fails with "minor version not supported"
when the minor version is not supported by the server.
My plan would not change this when "minorversion=N" is specified.
> Only
>if when a minorversion has NOT been specified should it silently
>use the highest common version.
Yes, that's my plan.
>>
>> 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.
Yes.
>>
>> 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.
The server end is passive. It either supports the minor version specified
in the RPC by the client and performs the RPC or it replies
NFS4ERR_MINOR_VERSION_MISMATCH if it does not support it.
The FreeBSD server already has sysctls:
vfs.nfsd.server_min_minorversion4
vfs.nfsd.server_max_minorversion4
that allows a sysadmin to limit the minor versions supported.
I think this satisfies your server requirement?
rick
> Yours,
> Daniel Ebdrup Jensen
--
Rod Grimes rgri...@freebsd.org
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: RFC: changing the default NFSv4 minor version?
I vote for this. +1 - Peter > On 14 May 2021, at 01:02, 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. > 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@freebsd.org mailing list > https://lists.freebsd.org/mailman/listinfo/freebsd-current > To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org" ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: RFC: changing the default NFSv4 minor version?
On Thu, May 13, 2021 at 5:02 PM 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. > 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 > +1 ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: RFC: changing the default NFSv4 minor version?
Daniel Ebdrup Jensen wrote: >On Thu, May 13, 2021 at 11:02:35PM +, 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. >>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@freebsd.org mailing list >>https://lists.freebsd.org/mailman/listinfo/freebsd-current >>To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org > >Hi Rick, > > If I understand your plans correctly, you're not going to be making > it so that minorversion=N complains? If by "complains" you mean "mount fails if the minor version is not supported by the server" then, yes, I am not planning on changing that. > 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. The POLA violation is that, now, a mount without "minorversion" always uses NFSv4.0 and fails to mount if the server does not support NFSv4.0. > At any rate, I'm all for it since I'm already using NFSv4.2. :) Thanks for the input, rick Yours, Daniel Ebdrup Jensen ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: RFC: changing the default NFSv4 minor version?
> On Thu, May 13, 2021 at 11:02:35PM +, 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@freebsd.org mailing list
> >https://lists.freebsd.org/mailman/listinfo/freebsd-current
> >To unsubscribe, send any mail to "freebsd-current-unsubscr...@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 rgri...@freebsd.org
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: RFC: changing the default NFSv4 minor version?
On Thu, May 13, 2021 at 11:02:35PM +, 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. 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@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org Hi Rick, If I understand your plans correctly, you're not going to be making it so that minorversion=N complains? 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. At any rate, I'm all for it since I'm already using NFSv4.2. :) Yours, Daniel Ebdrup Jensen signature.asc Description: PGP signature
RFC: changing the default NFSv4 minor version?
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. 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@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
