I will update mount.nfs so the default version is 4.1. I have two quick
questions on desired behavior:
o Should mounts that do not specify a minor version be upgraded to the
default minor version?
For example, should 'mount -overs=4' turn into 'mount -overs4.1', if the
current default is 4.1?
o If 'yes' to the above, should mount auto-retry decrementing minor
versions if EPROTONOSUPPORT?
For example, 'mount -overs=4' with a default of 4.2 would attempt: 4.2,
then 4.1, then 4.0.
Ben
> On Nov 11, 2014, at 9:39 AM, Benjamin Coddington <[email protected]> =
wrote:
>=20
> I will update mount.nfs so the default version is 4.1. I have two =
quick
> questions on desired behavior:
>=20
> o Should mounts that do not specify a minor version be upgraded to =
the default minor version?
>=20
> For example, should 'mount -overs=3D4' turn into 'mount -overs4.1', if =
the
> current default is 4.1?
No. We don=E2=80=99t want to change the minor version of mounts in =
users=E2=80=99 fstabs. The lack of a minor
version in mount options has always meant minor version 0.
What you=E2=80=99re talking about is making the default (i.e. when no =
version is specified) to be v4.1,
right? I think we definitely want to auto retry in this case, i.e. try =
v4.1, then v4.0, then v3.
-dros
>=20
>=20
> o If 'yes' to the above, should mount auto-retry decrementing minor
> versions if EPROTONOSUPPORT?
>=20
> For example, 'mount -overs=3D4' with a default of 4.2 would attempt: =
4.2,
> then 4.1, then 4.0.
>=20
> Ben
> --
> To unsubscribe from this list: send the line "unsubscribe linux-nfs" =
in
> the body of a message to [email protected]
> More majordomo info at http://vger.kernel.org/majordomo-info.html
On Tue, 11 Nov 2014, Weston Andros Adamson wrote:
>
> > On Nov 11, 2014, at 9:39 AM, Benjamin Coddington <[email protected]> wrote:
> >
> > I will update mount.nfs so the default version is 4.1. I have two quick
> > questions on desired behavior:
> >
> > o Should mounts that do not specify a minor version be upgraded to the default minor version?
> >
> > For example, should 'mount -overs=4' turn into 'mount -overs4.1', if the
> > current default is 4.1?
>
> No. We don’t want to change the minor version of mounts in users’ fstabs. The lack of a minor
> version in mount options has always meant minor version 0.
>
> What you’re talking about is making the default (i.e. when no version is specified) to be v4.1,
> right? I think we definitely want to auto retry in this case, i.e. try v4.1, then v4.0, then v3.
Correct. When no version is specified, it will be v4.1, and we'll
auto-retry. You are correct - my question is what do do when a major
version is specified, but not a minor version.
You're firmly on the side that lack of a minor version means use '0' for a
minor version.
The reason I ask: most would say if you're going to use v4, use v4.1. I
want to know if we want that general opinion reflected in the behavior of
mount choosing the current "best" minor version.
Ben
>
> -dros
>
> >
> >
> > o If 'yes' to the above, should mount auto-retry decrementing minor
> > versions if EPROTONOSUPPORT?
> >
> > For example, 'mount -overs=4' with a default of 4.2 would attempt: 4.2,
> > then 4.1, then 4.0.
> >
> > Ben
> > --
> > To unsubscribe from this list: send the line "unsubscribe linux-nfs" in
> > the body of a message to [email protected]
> > More majordomo info at http://vger.kernel.org/majordomo-info.html
>
>
Hi Ben,
On Tue, Nov 11, 2014 at 9:39 AM, Benjamin Coddington
<[email protected]> wrote:
> I will update mount.nfs so the default version is 4.1. I have two quick
> questions on desired behavior:
>
> o Should mounts that do not specify a minor version be upgraded to the
> default minor version?
>
> For example, should 'mount -overs=4' turn into 'mount -overs4.1', if the
> current default is 4.1?
>
>
> o If 'yes' to the above, should mount auto-retry decrementing minor
> versions if EPROTONOSUPPORT?
>
> For example, 'mount -overs=4' with a default of 4.2 would attempt: 4.2,
> then 4.1, then 4.0.
>
One thing you should note when doing this: the current parser for
/etc/nfsmount.conf does not support minor versions. I think it needs
to, so that we can continue to use it to set defaults.
...and to answer your questions above, I think that we should be able
to specify a 'default nfsv4 minor version' in /etc/nfsmount.conf, and
then negotiate down from there.
IOW: extend the 'Defaultvers' and 'Nfsvers' options to support 4.0,
4.1, 4.2,....
The result should be that If I do 'mount -t nfs' with no '-overs'
option, then we start at 4.1 (if that is the default in
/etc/nfsmount.conf) and then try 4.0, 3, 2 in that order.
If I do 'mount -t nfs -overs=4', then again consult /etc/nfsmount.conf;
- if there is a default matching a v4 minor version, then start at
that and negotiate down (but stop at 4.0).
- if there is no default in /etc/nfsmount.conf, then perhaps assume a
default of 0(????)
Cheers
Trond
--
Trond Myklebust
Linux NFS client maintainer, PrimaryData
[email protected]
On Tue, 11 Nov 2014, Trond Myklebust wrote:
> Hi Ben,
>
> On Tue, Nov 11, 2014 at 9:39 AM, Benjamin Coddington
> <[email protected]> wrote:
> > I will update mount.nfs so the default version is 4.1. I have two quick
> > questions on desired behavior:
> >
> > o Should mounts that do not specify a minor version be upgraded to the
> > default minor version?
> >
> > For example, should 'mount -overs=4' turn into 'mount -overs4.1', if the
> > current default is 4.1?
> >
> >
> > o If 'yes' to the above, should mount auto-retry decrementing minor
> > versions if EPROTONOSUPPORT?
> >
> > For example, 'mount -overs=4' with a default of 4.2 would attempt: 4.2,
> > then 4.1, then 4.0.
> >
>
> One thing you should note when doing this: the current parser for
> /etc/nfsmount.conf does not support minor versions. I think it needs
> to, so that we can continue to use it to set defaults.
>
> ...and to answer your questions above, I think that we should be able
> to specify a 'default nfsv4 minor version' in /etc/nfsmount.conf, and
> then negotiate down from there.
> IOW: extend the 'Defaultvers' and 'Nfsvers' options to support 4.0,
> 4.1, 4.2,....
Ah, good idea to make it configurable.
> The result should be that If I do 'mount -t nfs' with no '-overs'
> option, then we start at 4.1 (if that is the default in
> /etc/nfsmount.conf) and then try 4.0, 3, 2 in that order.
> If I do 'mount -t nfs -overs=4', then again consult /etc/nfsmount.conf;
> - if there is a default matching a v4 minor version, then start at
> that and negotiate down (but stop at 4.0).
Yep, those closely match the current behavior and that's what my first
pass looks like.
> - if there is no default in /etc/nfsmount.conf, then perhaps assume a
> default of 0(????)
That's the question, and I think it will be a very common case. Do we
want to have an idea of a "best" minor version, and use that if no minor
version is specified?
Ben
>
> Cheers
> Trond
>
>
> --
> Trond Myklebust
>
> Linux NFS client maintainer, PrimaryData
>
> [email protected]
>
On Tue, Nov 11, 2014 at 10:20 AM, Benjamin Coddington
<[email protected]> wrote:
>
>
> On Tue, 11 Nov 2014, Trond Myklebust wrote:
>
>> Hi Ben,
>>
>> On Tue, Nov 11, 2014 at 9:39 AM, Benjamin Coddington
>> <[email protected]> wrote:
>> > I will update mount.nfs so the default version is 4.1. I have two quick
>> > questions on desired behavior:
>> >
>> > o Should mounts that do not specify a minor version be upgraded to the
>> > default minor version?
>> >
>> > For example, should 'mount -overs=4' turn into 'mount -overs4.1', if the
>> > current default is 4.1?
>> >
>> >
>> > o If 'yes' to the above, should mount auto-retry decrementing minor
>> > versions if EPROTONOSUPPORT?
>> >
>> > For example, 'mount -overs=4' with a default of 4.2 would attempt: 4.2,
>> > then 4.1, then 4.0.
>> >
>>
>> One thing you should note when doing this: the current parser for
>> /etc/nfsmount.conf does not support minor versions. I think it needs
>> to, so that we can continue to use it to set defaults.
>>
>> ...and to answer your questions above, I think that we should be able
>> to specify a 'default nfsv4 minor version' in /etc/nfsmount.conf, and
>> then negotiate down from there.
>> IOW: extend the 'Defaultvers' and 'Nfsvers' options to support 4.0,
>> 4.1, 4.2,....
>
> Ah, good idea to make it configurable.
>
>> The result should be that If I do 'mount -t nfs' with no '-overs'
>> option, then we start at 4.1 (if that is the default in
>> /etc/nfsmount.conf) and then try 4.0, 3, 2 in that order.
>> If I do 'mount -t nfs -overs=4', then again consult /etc/nfsmount.conf;
>> - if there is a default matching a v4 minor version, then start at
>> that and negotiate down (but stop at 4.0).
>
> Yep, those closely match the current behavior and that's what my first
> pass looks like.
>
>> - if there is no default in /etc/nfsmount.conf, then perhaps assume a
>> default of 0(????)
>
> That's the question, and I think it will be a very common case. Do we
> want to have an idea of a "best" minor version, and use that if no minor
> version is specified?
My hunch would be that if nothing is specified in /etc/nfsmount.conf,
then we should stick to the current default (i.e. 4==4.0) so that we
do not break existing setups.
Cheers
Trond
--
Trond Myklebust
Linux NFS client maintainer, PrimaryData
[email protected]
Hi Ben,
On 11/11/2014 10:20 AM, Benjamin Coddington wrote:
>
> On Tue, 11 Nov 2014, Trond Myklebust wrote:
>
>> Hi Ben,
>>
>> On Tue, Nov 11, 2014 at 9:39 AM, Benjamin Coddington
>> <[email protected]> wrote:
>>> I will update mount.nfs so the default version is 4.1. I have two quick
>>> questions on desired behavior:
>>>
>>> o Should mounts that do not specify a minor version be upgraded to the
>>> default minor version?
>>>
>>> For example, should 'mount -overs=4' turn into 'mount -overs4.1', if the
>>> current default is 4.1?
>>>
>>>
>>> o If 'yes' to the above, should mount auto-retry decrementing minor
>>> versions if EPROTONOSUPPORT?
>>>
>>> For example, 'mount -overs=4' with a default of 4.2 would attempt: 4.2,
>>> then 4.1, then 4.0.
>>>
>> One thing you should note when doing this: the current parser for
>> /etc/nfsmount.conf does not support minor versions. I think it needs
>> to, so that we can continue to use it to set defaults.
>>
>> ...and to answer your questions above, I think that we should be able
>> to specify a 'default nfsv4 minor version' in /etc/nfsmount.conf, and
>> then negotiate down from there.
>> IOW: extend the 'Defaultvers' and 'Nfsvers' options to support 4.0,
>> 4.1, 4.2,....
> Ah, good idea to make it configurable.
>
>> The result should be that If I do 'mount -t nfs' with no '-overs'
>> option, then we start at 4.1 (if that is the default in
>> /etc/nfsmount.conf) and then try 4.0, 3, 2 in that order.
>> If I do 'mount -t nfs -overs=4', then again consult /etc/nfsmount.conf;
>> - if there is a default matching a v4 minor version, then start at
>> that and negotiate down (but stop at 4.0).
> Yep, those closely match the current behavior and that's what my first
> pass looks like.
>
>> - if there is no default in /etc/nfsmount.conf, then perhaps assume a
>> default of 0(????)
> That's the question, and I think it will be a very common case. Do we
> want to have an idea of a "best" minor version, and use that if no minor
> version is specified?
I don't think so. Right now users know that if they don't use a minor version then they'll be getting a v4.0 mount. I think we should keep this behavior so we don't accidentally break people's configuration.
Anna
>
> Ben
>
>> Cheers
>> Trond
>>
>>
>> --
>> Trond Myklebust
>>
>> Linux NFS client maintainer, PrimaryData
>>
>> [email protected]
>>
> --
> To unsubscribe from this list: send the line "unsubscribe linux-nfs" in
> the body of a message to [email protected]
> More majordomo info at http://vger.kernel.org/majordomo-info.html
On 11/11/2014 05:27 PM, Anna Schumaker wrote:
>
> I don't think so. Right now users know that if they don't use a minor
> version then they'll be getting a v4.0 mount. I think we should keep
> this behavior so we don't accidentally break people's configuration.
>
This would be inconsistent and there for unexpected.
What you suggest is:
* if user specifies no version then start with 4.1, work down to supported version
* if user specifies major=4 only try 4.0
* if user specifies major.minor only try major.minor
I think a more expect behavior would be:
* if user specifies no version then start with 4.1, work down to supported version
* if user specifies major=4 start with 4.1 til 4.0
* if user specifies major.minor only try major.minor
The preferred (implicit) minor is 1 in all cases
The question is did users of major=4 meant 4.0 and were lazy to type ".0"
or did they mean "don't try 3 or 2"
Current system compatibility is already changing by moving all
case 1 above from 4.0 to 4.1 by the next yum update. I think it would
be reasonable to also change case 2. And have a consistent semantics.
> Anna
>
Thanks
Boaz
> > I don't think so. Right now users know that if they don't use a =
minor
> > version then they'll be getting a v4.0 mount. I think we should keep
> > this behavior so we don't accidentally break people's configuration.
> >
>=20
> This would be inconsistent and there for unexpected.
>=20
> What you suggest is:
> * if user specifies no version then start with 4.1, work down to =
supported
> version
> * if user specifies major=3D4 only try 4.0
> * if user specifies major.minor only try major.minor
>=20
> I think a more expect behavior would be:
> * if user specifies no version then start with 4.1, work down to =
supported
> version
> * if user specifies major=3D4 start with 4.1 til 4.0
> * if user specifies major.minor only try major.minor
>=20
> The preferred (implicit) minor is 1 in all cases
>=20
> The question is did users of major=3D4 meant 4.0 and were lazy to type =
".0"
> or did they mean "don't try 3 or 2"
Have we always allowed specifying 4.0? Or was there a time when you =
could only specify 4 (meaning 4.0)?
If the latter, then backwards compatibility suggests 4 should mean 4.0.
> Current system compatibility is already changing by moving all case 1 =
above
> from 4.0 to 4.1 by the next yum update. I think it would be reasonable =
to also
> change case 2. And have a consistent semantics.
Frank
On 11/11/2014 11:27 AM, Boaz Harrosh wrote:
> On 11/11/2014 05:27 PM, Anna Schumaker wrote:
>
>>
>> I don't think so. Right now users know that if they don't use a minor
>> version then they'll be getting a v4.0 mount. I think we should keep
>> this behavior so we don't accidentally break people's configuration.
>>
>
> This would be inconsistent and there for unexpected.
>
> What you suggest is:
> * if user specifies no version then start with 4.1, work down to supported version
> * if user specifies major=4 only try 4.0
> * if user specifies major.minor only try major.minor
>
> I think a more expect behavior would be:
> * if user specifies no version then start with 4.1, work down to supported version
> * if user specifies major=4 start with 4.1 til 4.0
> * if user specifies major.minor only try major.minor
I agree with Boaz... This makes more sense, IMHO...
We put all this work to make 4.1 the better minor version
and then we are not going to default to it when -o v4 is used?
At the end of the day, which minor version is being
used should be seamless to the user. So when they
specify -o v4, we'll decide which minor version
should be used, as long as there is a way to
override it (which there will be).
steved.
>
> The preferred (implicit) minor is 1 in all cases
>
> The question is did users of major=4 meant 4.0 and were lazy to type ".0"
> or did they mean "don't try 3 or 2"
>
> Current system compatibility is already changing by moving all
> case 1 above from 4.0 to 4.1 by the next yum update. I think it would
> be reasonable to also change case 2. And have a consistent semantics.
>
>> Anna
>>
>
> Thanks
> Boaz
>
> --
> To unsubscribe from this list: send the line "unsubscribe linux-nfs" in
> the body of a message to [email protected]
> More majordomo info at http://vger.kernel.org/majordomo-info.html
>
On 11/11/2014 10:01 AM, Trond Myklebust wrote:
> One thing you should note when doing this: the current parser for
> /etc/nfsmount.conf does not support minor versions. I think it needs
> to, so that we can continue to use it to set defaults.
Well setting Nfsvers=4.1 will give you a v4.1 mounts (assuming
the server supports v4.1. but setting Defaultvers=4.1 does
give you a v4.0 mount, which will need to be fixed.
>
> ...and to answer your questions above, I think that we should be able
> to specify a 'default nfsv4 minor version' in /etc/nfsmount.conf, and
> then negotiate down from there.
> IOW: extend the 'Defaultvers' and 'Nfsvers' options to support 4.0,
> 4.1, 4.2,....
Well Defaultvers is a negotiation with the server, Nfsvers is not.
So when Nfsvers set set there is no negotiation, they get what is
set to (aka 3, 4, 4.0, 4.1, just like the command line).
With Defaultvers its a negotiation so set it to highest
version and let it go... I'm not sure we need another
variable to complicate things...
>
> The result should be that If I do 'mount -t nfs' with no '-overs'
> option, then we start at 4.1 (if that is the default in
> /etc/nfsmount.conf) and then try 4.0, 3, 2 in that order.
> If I do 'mount -t nfs -overs=4', then again consult /etc/nfsmount.conf;
> - if there is a default matching a v4 minor version, then start at
> that and negotiate down (but stop at 4.0).
Again, I'm thinking this type of complexity is not needed (especially
from a testing matrix point of view).
besides, if someone is specifying a version on the command line, is most likely
they are not going to be using /etc/nfsmount.conf as all...
> - if there is no default in /etc/nfsmount.conf, then perhaps assume a
> default of 0(????)
I'm thinking why not default to the better minor version?? 4.1 => 4.0 => 3
steved.
On Tue, Nov 11, 2014 at 2:16 PM, Steve Dickson <[email protected]> wrote:
>
>
> On 11/11/2014 10:01 AM, Trond Myklebust wrote:
>> One thing you should note when doing this: the current parser for
>> /etc/nfsmount.conf does not support minor versions. I think it needs
>> to, so that we can continue to use it to set defaults.
> Well setting Nfsvers=4.1 will give you a v4.1 mounts (assuming
> the server supports v4.1. but setting Defaultvers=4.1 does
> give you a v4.0 mount, which will need to be fixed.
>
>>
>> ...and to answer your questions above, I think that we should be able
>> to specify a 'default nfsv4 minor version' in /etc/nfsmount.conf, and
>> then negotiate down from there.
>> IOW: extend the 'Defaultvers' and 'Nfsvers' options to support 4.0,
>> 4.1, 4.2,....
> Well Defaultvers is a negotiation with the server, Nfsvers is not.
> So when Nfsvers set set there is no negotiation, they get what is
> set to (aka 3, 4, 4.0, 4.1, just like the command line).
>
> With Defaultvers its a negotiation so set it to highest
> version and let it go... I'm not sure we need another
> variable to complicate things...
>
>>
>> The result should be that If I do 'mount -t nfs' with no '-overs'
>> option, then we start at 4.1 (if that is the default in
>> /etc/nfsmount.conf) and then try 4.0, 3, 2 in that order.
>> If I do 'mount -t nfs -overs=4', then again consult /etc/nfsmount.conf;
>> - if there is a default matching a v4 minor version, then start at
>> that and negotiate down (but stop at 4.0).
> Again, I'm thinking this type of complexity is not needed (especially
> from a testing matrix point of view).
>
> besides, if someone is specifying a version on the command line, is most likely
> they are not going to be using /etc/nfsmount.conf as all...
>
>> - if there is no default in /etc/nfsmount.conf, then perhaps assume a
>> default of 0(????)
> I'm thinking why not default to the better minor version?? 4.1 => 4.0 => 3
So at which minor version do you start? 4.10, 4.100?...
We don't want to have to recompile mount every time we add a new minor
version in order to bump the maximum number, which is why I think we
want to use /etc/nfsmount.conf and Defaultvers to define that (and
assume '0' if undefined).
--
Trond Myklebust
Linux NFS client maintainer, PrimaryData
[email protected]
On 11/11/2014 03:43 PM, Trond Myklebust wrote:
> On Tue, Nov 11, 2014 at 2:16 PM, Steve Dickson <[email protected]> wrote:
>>
>>
>> On 11/11/2014 10:01 AM, Trond Myklebust wrote:
>>> One thing you should note when doing this: the current parser for
>>> /etc/nfsmount.conf does not support minor versions. I think it needs
>>> to, so that we can continue to use it to set defaults.
>> Well setting Nfsvers=4.1 will give you a v4.1 mounts (assuming
>> the server supports v4.1. but setting Defaultvers=4.1 does
>> give you a v4.0 mount, which will need to be fixed.
>>
>>>
>>> ...and to answer your questions above, I think that we should be able
>>> to specify a 'default nfsv4 minor version' in /etc/nfsmount.conf, and
>>> then negotiate down from there.
>>> IOW: extend the 'Defaultvers' and 'Nfsvers' options to support 4.0,
>>> 4.1, 4.2,....
>> Well Defaultvers is a negotiation with the server, Nfsvers is not.
>> So when Nfsvers set set there is no negotiation, they get what is
>> set to (aka 3, 4, 4.0, 4.1, just like the command line).
>>
>> With Defaultvers its a negotiation so set it to highest
>> version and let it go... I'm not sure we need another
>> variable to complicate things...
>>
>>>
>>> The result should be that If I do 'mount -t nfs' with no '-overs'
>>> option, then we start at 4.1 (if that is the default in
>>> /etc/nfsmount.conf) and then try 4.0, 3, 2 in that order.
>>> If I do 'mount -t nfs -overs=4', then again consult /etc/nfsmount.conf;
>>> - if there is a default matching a v4 minor version, then start at
>>> that and negotiate down (but stop at 4.0).
>> Again, I'm thinking this type of complexity is not needed (especially
>> from a testing matrix point of view).
>>
>> besides, if someone is specifying a version on the command line, is most likely
>> they are not going to be using /etc/nfsmount.conf as all...
>>
>>> - if there is no default in /etc/nfsmount.conf, then perhaps assume a
>>> default of 0(????)
>> I'm thinking why not default to the better minor version?? 4.1 => 4.0 => 3
>
> So at which minor version do you start? 4.10, 4.100?...
The highest one.... Set Defaultvers to the highest version
(including minor version) and then let the negotiations happen.
> We don't want to have to recompile mount every time we add a new minor
> version in order to bump the maximum number, which is why I think we
> want to use /etc/nfsmount.conf and Defaultvers to define that (and
> assume '0' if undefined).
I agree. The fact that you can't set DefaultVers=4.2 and then
negotiated down to what both sides support (even if its v3)
is a problem and needs to be fixed.
My point is I don't think we need another variable, say
DefaultMinVers, that defines the minor version of v4. I'm
thinking that's its overkill and adds unnecessary complexity.
steved.
On Wed, Nov 12, 2014 at 8:08 AM, Steve Dickson <[email protected]> wrote:
>
>
> On 11/11/2014 03:43 PM, Trond Myklebust wrote:
>> On Tue, Nov 11, 2014 at 2:16 PM, Steve Dickson <[email protected]> wrote:
>>>
>>>
>>> On 11/11/2014 10:01 AM, Trond Myklebust wrote:
>>>> One thing you should note when doing this: the current parser for
>>>> /etc/nfsmount.conf does not support minor versions. I think it needs
>>>> to, so that we can continue to use it to set defaults.
>>> Well setting Nfsvers=4.1 will give you a v4.1 mounts (assuming
>>> the server supports v4.1. but setting Defaultvers=4.1 does
>>> give you a v4.0 mount, which will need to be fixed.
>>>
>>>>
>>>> ...and to answer your questions above, I think that we should be able
>>>> to specify a 'default nfsv4 minor version' in /etc/nfsmount.conf, and
>>>> then negotiate down from there.
>>>> IOW: extend the 'Defaultvers' and 'Nfsvers' options to support 4.0,
>>>> 4.1, 4.2,....
>>> Well Defaultvers is a negotiation with the server, Nfsvers is not.
>>> So when Nfsvers set set there is no negotiation, they get what is
>>> set to (aka 3, 4, 4.0, 4.1, just like the command line).
>>>
>>> With Defaultvers its a negotiation so set it to highest
>>> version and let it go... I'm not sure we need another
>>> variable to complicate things...
>>>
>>>>
>>>> The result should be that If I do 'mount -t nfs' with no '-overs'
>>>> option, then we start at 4.1 (if that is the default in
>>>> /etc/nfsmount.conf) and then try 4.0, 3, 2 in that order.
>>>> If I do 'mount -t nfs -overs=4', then again consult /etc/nfsmount.conf;
>>>> - if there is a default matching a v4 minor version, then start at
>>>> that and negotiate down (but stop at 4.0).
>>> Again, I'm thinking this type of complexity is not needed (especially
>>> from a testing matrix point of view).
>>>
>>> besides, if someone is specifying a version on the command line, is most likely
>>> they are not going to be using /etc/nfsmount.conf as all...
>>>
>>>> - if there is no default in /etc/nfsmount.conf, then perhaps assume a
>>>> default of 0(????)
>>> I'm thinking why not default to the better minor version?? 4.1 => 4.0 => 3
>>
>> So at which minor version do you start? 4.10, 4.100?...
> The highest one.... Set Defaultvers to the highest version
> (including minor version) and then let the negotiations happen.
>
>> We don't want to have to recompile mount every time we add a new minor
>> version in order to bump the maximum number, which is why I think we
>> want to use /etc/nfsmount.conf and Defaultvers to define that (and
>> assume '0' if undefined).
> I agree. The fact that you can't set DefaultVers=4.2 and then
> negotiated down to what both sides support (even if its v3)
> is a problem and needs to be fixed.
>
> My point is I don't think we need another variable, say
> DefaultMinVers, that defines the minor version of v4. I'm
> thinking that's its overkill and adds unnecessary complexity.
>
I never said we do.
I think we're in agreement mostly; the only point where I see
disagreement is when Defaultvers is unset.
My position is that in that situation, we don't know what starting
point to use for minor version negotiation, and so we should just
default to minor version 0: if the sysadmin want a different default,
then the answer is to set Defaultvers...
Cheers
Trond
--
Trond Myklebust
Linux NFS client maintainer, PrimaryData
[email protected]
On 11/12/2014 09:31 AM, Trond Myklebust wrote:
>> My point is I don't think we need another variable, say
>> > DefaultMinVers, that defines the minor version of v4. I'm
>> > thinking that's its overkill and adds unnecessary complexity.
>> >
> I never said we do.
Ok... I misunderstood...
>
> I think we're in agreement mostly; the only point where I see
> disagreement is when Defaultvers is unset.
> My position is that in that situation, we don't know what starting
> point to use for minor version negotiation, and so we should just
> default to minor version 0: if the sysadmin want a different default,
> then the answer is to set Defaultvers...
Gotta... and there is a disagreement... I saying we make the
default the highest supported minor version. With the
Linux client and server that's v4.2. So when no option is
given and Defaultvers is not set, try 4.2, then 4.1 and
then 4.0 and finally v3.
But I do see your point of not having to recompile mount
when we want to change the default minor release so
how that default is set is the question... Maybe
an environment variable??
One down side of being the aggressive with minor version
negotiation is legacy servers (aka AIX). Today we
don't negotiate well with those types of servers...
Its not our fault, but is a problem...
steved.
On Wed, Nov 12, 2014 at 10:10 AM, Steve Dickson <[email protected]> wrote:
>
>
> On 11/12/2014 09:31 AM, Trond Myklebust wrote:
>>> My point is I don't think we need another variable, say
>>> > DefaultMinVers, that defines the minor version of v4. I'm
>>> > thinking that's its overkill and adds unnecessary complexity.
>>> >
>> I never said we do.
> Ok... I misunderstood...
>
>>
>> I think we're in agreement mostly; the only point where I see
>> disagreement is when Defaultvers is unset.
>> My position is that in that situation, we don't know what starting
>> point to use for minor version negotiation, and so we should just
>> default to minor version 0: if the sysadmin want a different default,
>> then the answer is to set Defaultvers...
> Gotta... and there is a disagreement... I saying we make the
> default the highest supported minor version. With the
> Linux client and server that's v4.2. So when no option is
> given and Defaultvers is not set, try 4.2, then 4.1 and
> then 4.0 and finally v3.
Only for Linux 3.11 and newer, and only if they enable CONFIG_NFS_V4_2
/ CONFIG_NFSD_V4_SECURITY_LABEL.
Unless we want to have different defaults for older kernels, this sort
of implies that we're moving in the direction of coupling the
nfs-utils releases more tightly to the kernel version. I'm neutral to
that, but I do want to call it out.
> But I do see your point of not having to recompile mount
> when we want to change the default minor release so
> how that default is set is the question... Maybe
> an environment variable??
That's still something that requires a user or sysadmin action, and it
wouldn't really play well with autofs and its ilk. As Marie Antoinette
would say: "Let them edit /etc/nfsmount.conf"
> One down side of being the aggressive with minor version
> negotiation is legacy servers (aka AIX). Today we
> don't negotiate well with those types of servers...
> Its not our fault, but is a problem...
Is this because they don't implement that part of RFC3530?
--
Trond Myklebust
Linux NFS client maintainer, PrimaryData
[email protected]
On Nov 12, 2014, at 9:28 AM, Trond Myklebust =
<[email protected]> wrote:
> On Wed, Nov 12, 2014 at 10:10 AM, Steve Dickson <[email protected]> =
wrote:
>>=20
>>=20
>> On 11/12/2014 09:31 AM, Trond Myklebust wrote:
>>>> My point is I don't think we need another variable, say
>>>>> DefaultMinVers, that defines the minor version of v4. I'm
>>>>> thinking that's its overkill and adds unnecessary complexity.
>>>>>=20
>>> I never said we do.
>> Ok... I misunderstood...
>>=20
>>>=20
>>> I think we're in agreement mostly; the only point where I see
>>> disagreement is when Defaultvers is unset.
>>> My position is that in that situation, we don't know what starting
>>> point to use for minor version negotiation, and so we should just
>>> default to minor version 0: if the sysadmin want a different =
default,
>>> then the answer is to set Defaultvers...
>> Gotta... and there is a disagreement... I saying we make the
>> default the highest supported minor version. With the
>> Linux client and server that's v4.2. So when no option is
>> given and Defaultvers is not set, try 4.2, then 4.1 and
>> then 4.0 and finally v3.
>=20
> Only for Linux 3.11 and newer, and only if they enable CONFIG_NFS_V4_2
> / CONFIG_NFSD_V4_SECURITY_LABEL.
>=20
> Unless we want to have different defaults for older kernels, this sort
> of implies that we're moving in the direction of coupling the
> nfs-utils releases more tightly to the kernel version. I'm neutral to
> that, but I do want to call it out.
>=20
>> But I do see your point of not having to recompile mount
>> when we want to change the default minor release so
>> how that default is set is the question... Maybe
>> an environment variable??
>=20
> That's still something that requires a user or sysadmin action, and it
> wouldn't really play well with autofs and its ilk. As Marie Antoinette
> would say: "Let them edit /etc/nfsmount.conf=94
Fwiw: I thought this was the whole point of nfsmount.conf.
We should be able to rev nfs-utils while preserving the
administrator=92s locally chosen default settings.
+1 for using /etc/nfsmount.conf for this.
>=20
>> One down side of being the aggressive with minor version
>> negotiation is legacy servers (aka AIX). Today we
>> don't negotiate well with those types of servers...
>> Its not our fault, but is a problem...
>=20
> Is this because they don't implement that part of RFC3530?
>=20
> --=20
> Trond Myklebust
>=20
> Linux NFS client maintainer, PrimaryData
>=20
> [email protected]
> --
> To unsubscribe from this list: send the line "unsubscribe linux-nfs" =
in
> the body of a message to [email protected]
> More majordomo info at http://vger.kernel.org/majordomo-info.html
--
Chuck Lever
chuck[dot]lever[at]oracle[dot]com
On 11/12/2014 10:37 AM, Chuck Lever wrote:
>>> But I do see your point of not having to recompile mount
>>> >> when we want to change the default minor release so
>>> >> how that default is set is the question... Maybe
>>> >> an environment variable??
>> >
>> > That's still something that requires a user or sysadmin action, and it
>> > wouldn't really play well with autofs and its ilk. As Marie Antoinette
>> > would say: "Let them edit /etc/nfsmount.conf?
> Fwiw: I thought this was the whole point of nfsmount.conf.
> We should be able to rev nfs-utils while preserving the
> administrator?s locally chosen default settings.
>
> +1 for using /etc/nfsmount.conf for this.
>
The reason the files exists is when we move the default
version from v3 to v4 there would be away move the
default back to v3 for legacy servers. Way
way to move back from the future, if you will ;-)
I never thought we would used it to go forward,
just back...
The problem with setting defaults in nfsmount.conf
its not scalable especially in very large
installations. I get it that distros can set
it during installation, but that becomes error prone
when different nfs-utils are used with different
kernels. I think we should be more dynamic
I think we barrow a paradigm from the server. On
server the supported protocols are in /proc/fs/nfsd/verions
that rpc.nfsd reads. We should do the same thing on the
client.
The kernel will tell mount.nfs where to start the negotiation.
This will stop mount.nfs for needing to be compiled
on minor version updates, plus it solves the problem
of different kernels having different protocols enabled.
I think this approach much more dynamic and it
seems to work on the server side...
steved.
On Wed, Nov 12, 2014 at 1:10 PM, Steve Dickson <[email protected]> wrote:
>
>
> On 11/12/2014 10:37 AM, Chuck Lever wrote:
>>>> But I do see your point of not having to recompile mount
>>>> >> when we want to change the default minor release so
>>>> >> how that default is set is the question... Maybe
>>>> >> an environment variable??
>>> >
>>> > That's still something that requires a user or sysadmin action, and i=
t
>>> > wouldn't really play well with autofs and its ilk. As Marie Antoinett=
e
>>> > would say: "Let them edit /etc/nfsmount.conf=E2=80=9D
>> Fwiw: I thought this was the whole point of nfsmount.conf.
>> We should be able to rev nfs-utils while preserving the
>> administrator=E2=80=99s locally chosen default settings.
>>
>> +1 for using /etc/nfsmount.conf for this.
>>
> The reason the files exists is when we move the default
> version from v3 to v4 there would be away move the
> default back to v3 for legacy servers. Way
> way to move back from the future, if you will ;-)
> I never thought we would used it to go forward,
> just back...
>
> The problem with setting defaults in nfsmount.conf
> its not scalable especially in very large
> installations. I get it that distros can set
> it during installation, but that becomes error prone
> when different nfs-utils are used with different
> kernels. I think we should be more dynamic
>
> I think we barrow a paradigm from the server. On
> server the supported protocols are in /proc/fs/nfsd/verions
> that rpc.nfsd reads. We should do the same thing on the
> client.
>
> The kernel will tell mount.nfs where to start the negotiation.
>
> This will stop mount.nfs for needing to be compiled
> on minor version updates, plus it solves the problem
> of different kernels having different protocols enabled.
>
> I think this approach much more dynamic and it
> seems to work on the server side...
>
The NFS client modules are loaded on demand. The kernel will therefore
not actually know the capabilities until we attempt the mount.
--=20
Trond Myklebust
Linux NFS client maintainer, PrimaryData
[email protected]
On Wed, Nov 12, 2014 at 01:41:03PM -0500, Trond Myklebust wrote:
> The NFS client modules are loaded on demand. The kernel will therefore
> not actually know the capabilities until we attempt the mount.
Right, but the main nfs module can know at least an upper bound, and
that's all mount needs to start negotiation, isn't it? If the kernel
thinks 4.99 is supported but in fact that module turns out to be
blacklisted or something, then we can always try it and fall back.
--b.
On 11/12/2014 03:07 PM, J. Bruce Fields wrote:
> On Wed, Nov 12, 2014 at 01:41:03PM -0500, Trond Myklebust wrote:
>> The NFS client modules are loaded on demand. The kernel will therefore
>> not actually know the capabilities until we attempt the mount.
>
> Right, but the main nfs module can know at least an upper bound, and
> that's all mount needs to start negotiation, isn't it? If the kernel
> thinks 4.99 is supported but in fact that module turns out to be
> blacklisted or something, then we can always try it and fall back.
>
Right, all mount.nfs needs to know is where to start...
I was thinking mount.nfs to try to load the module but
that's probably not a good idea...
steved.
On 11/12/2014 01:41 PM, Trond Myklebust wrote:
> On Wed, Nov 12, 2014 at 1:10 PM, Steve Dickson <[email protected]> wrote:
>>
>> On 11/12/2014 10:37 AM, Chuck Lever wrote:
>>>>> But I do see your point of not having to recompile mount
>>>>>>> when we want to change the default minor release so
>>>>>>> how that default is set is the question... Maybe
>>>>>>> an environment variable??
>>>>> That's still something that requires a user or sysadmin action, and it
>>>>> wouldn't really play well with autofs and its ilk. As Marie Antoinette
>>>>> would say: "Let them edit /etc/nfsmount.conf”
>>> Fwiw: I thought this was the whole point of nfsmount.conf.
>>> We should be able to rev nfs-utils while preserving the
>>> administrator’s locally chosen default settings.
>>>
>>> +1 for using /etc/nfsmount.conf for this.
>>>
>> The reason the files exists is when we move the default
>> version from v3 to v4 there would be away move the
>> default back to v3 for legacy servers. Way
>> way to move back from the future, if you will ;-)
>> I never thought we would used it to go forward,
>> just back...
>>
>> The problem with setting defaults in nfsmount.conf
>> its not scalable especially in very large
>> installations. I get it that distros can set
>> it during installation, but that becomes error prone
>> when different nfs-utils are used with different
>> kernels. I think we should be more dynamic
>>
>> I think we barrow a paradigm from the server. On
>> server the supported protocols are in /proc/fs/nfsd/verions
>> that rpc.nfsd reads. We should do the same thing on the
>> client.
>>
>> The kernel will tell mount.nfs where to start the negotiation.
>>
>> This will stop mount.nfs for needing to be compiled
>> on minor version updates, plus it solves the problem
>> of different kernels having different protocols enabled.
>>
>> I think this approach much more dynamic and it
>> seems to work on the server side...
>>
> The NFS client modules are loaded on demand. The kernel will therefore
> not actually know the capabilities until we attempt the mount.
>
>
NFS v4.0, 4.1, and 4.2 are all part of the same module, though. Is there a way to analyze modules and determine what is compiled in?
Anna
On 11/12/2014 03:17 PM, Anna Schumaker wrote:
> On 11/12/2014 01:41 PM, Trond Myklebust wrote:
>> On Wed, Nov 12, 2014 at 1:10 PM, Steve Dickson <[email protected]> wrote:
>>>
>>> On 11/12/2014 10:37 AM, Chuck Lever wrote:
>>>>>> But I do see your point of not having to recompile mount
>>>>>>>> when we want to change the default minor release so
>>>>>>>> how that default is set is the question... Maybe
>>>>>>>> an environment variable??
>>>>>> That's still something that requires a user or sysadmin action, and it
>>>>>> wouldn't really play well with autofs and its ilk. As Marie Antoinette
>>>>>> would say: "Let them edit /etc/nfsmount.conf”
>>>> Fwiw: I thought this was the whole point of nfsmount.conf.
>>>> We should be able to rev nfs-utils while preserving the
>>>> administrator’s locally chosen default settings.
>>>>
>>>> +1 for using /etc/nfsmount.conf for this.
>>>>
>>> The reason the files exists is when we move the default
>>> version from v3 to v4 there would be away move the
>>> default back to v3 for legacy servers. Way
>>> way to move back from the future, if you will ;-)
>>> I never thought we would used it to go forward,
>>> just back...
>>>
>>> The problem with setting defaults in nfsmount.conf
>>> its not scalable especially in very large
>>> installations. I get it that distros can set
>>> it during installation, but that becomes error prone
>>> when different nfs-utils are used with different
>>> kernels. I think we should be more dynamic
>>>
>>> I think we barrow a paradigm from the server. On
>>> server the supported protocols are in /proc/fs/nfsd/verions
>>> that rpc.nfsd reads. We should do the same thing on the
>>> client.
>>>
>>> The kernel will tell mount.nfs where to start the negotiation.
>>>
>>> This will stop mount.nfs for needing to be compiled
>>> on minor version updates, plus it solves the problem
>>> of different kernels having different protocols enabled.
>>>
>>> I think this approach much more dynamic and it
>>> seems to work on the server side...
>>>
>> The NFS client modules are loaded on demand. The kernel will therefore
>> not actually know the capabilities until we attempt the mount.
>>
>>
> NFS v4.0, 4.1, and 4.2 are all part of the same module, though. Is there a way to analyze modules and determine what is compiled in?
Maybe come up with some global bit field could be used?
Each bit signifies a minor version is enabled...
steved.
On Wed, Nov 12, 2014 at 3:32 PM, Steve Dickson <[email protected]> wrote:
>
>
> On 11/12/2014 03:17 PM, Anna Schumaker wrote:
>> On 11/12/2014 01:41 PM, Trond Myklebust wrote:
>>> On Wed, Nov 12, 2014 at 1:10 PM, Steve Dickson <[email protected]> wrot=
e:
>>>>
>>>> On 11/12/2014 10:37 AM, Chuck Lever wrote:
>>>>>>> But I do see your point of not having to recompile mount
>>>>>>>>> when we want to change the default minor release so
>>>>>>>>> how that default is set is the question... Maybe
>>>>>>>>> an environment variable??
>>>>>>> That's still something that requires a user or sysadmin action, and=
it
>>>>>>> wouldn't really play well with autofs and its ilk. As Marie Antoine=
tte
>>>>>>> would say: "Let them edit /etc/nfsmount.conf=E2=80=9D
>>>>> Fwiw: I thought this was the whole point of nfsmount.conf.
>>>>> We should be able to rev nfs-utils while preserving the
>>>>> administrator=E2=80=99s locally chosen default settings.
>>>>>
>>>>> +1 for using /etc/nfsmount.conf for this.
>>>>>
>>>> The reason the files exists is when we move the default
>>>> version from v3 to v4 there would be away move the
>>>> default back to v3 for legacy servers. Way
>>>> way to move back from the future, if you will ;-)
>>>> I never thought we would used it to go forward,
>>>> just back...
>>>>
>>>> The problem with setting defaults in nfsmount.conf
>>>> its not scalable especially in very large
>>>> installations. I get it that distros can set
>>>> it during installation, but that becomes error prone
>>>> when different nfs-utils are used with different
>>>> kernels. I think we should be more dynamic
>>>>
>>>> I think we barrow a paradigm from the server. On
>>>> server the supported protocols are in /proc/fs/nfsd/verions
>>>> that rpc.nfsd reads. We should do the same thing on the
>>>> client.
>>>>
>>>> The kernel will tell mount.nfs where to start the negotiation.
>>>>
>>>> This will stop mount.nfs for needing to be compiled
>>>> on minor version updates, plus it solves the problem
>>>> of different kernels having different protocols enabled.
>>>>
>>>> I think this approach much more dynamic and it
>>>> seems to work on the server side...
>>>>
>>> The NFS client modules are loaded on demand. The kernel will therefore
>>> not actually know the capabilities until we attempt the mount.
>>>
>>>
>> NFS v4.0, 4.1, and 4.2 are all part of the same module, though. Is ther=
e a way to analyze modules and determine what is compiled in?
> Maybe come up with some global bit field could be used?
> Each bit signifies a minor version is enabled...
>
No. This means that mount.nfs now suddenly needs to know the names of
the NFS modules and how to load them before it calls mount() just so
that it knows which parameters to try. This is a rathole we don't want
to explore...
--=20
Trond Myklebust
Linux NFS client maintainer, PrimaryData
[email protected]
On 11/12/2014 05:42 PM, Trond Myklebust wrote:
>>> NFS v4.0, 4.1, and 4.2 are all part of the same module, though. Is there a way to analyze modules and determine what is compiled in?
>> > Maybe come up with some global bit field could be used?
>> > Each bit signifies a minor version is enabled...
>> >
> No. This means that mount.nfs now suddenly needs to know the names of
> the NFS modules and how to load them before it calls mount() just so
> that it knows which parameters to try. This is a rathole we don't want
> to explore...
I don't think mount.nfs needs to know any names... Just
a file /proc/fs/nfs/mount that tells mount.nfs where
to start the negotiation....
steved.
On Thu, Nov 13, 2014 at 12:57 PM, Steve Dickson <[email protected]> wrote:
> On 11/12/2014 05:42 PM, Trond Myklebust wrote:
>>>> NFS v4.0, 4.1, and 4.2 are all part of the same module, though. Is there a way to analyze modules and determine what is compiled in?
>>> > Maybe come up with some global bit field could be used?
>>> > Each bit signifies a minor version is enabled...
>>> >
>> No. This means that mount.nfs now suddenly needs to know the names of
>> the NFS modules and how to load them before it calls mount() just so
>> that it knows which parameters to try. This is a rathole we don't want
>> to explore...
> I don't think mount.nfs needs to know any names... Just
> a file /proc/fs/nfs/mount that tells mount.nfs where
> to start the negotiation....
>
The kernel does not have that information until the NFSv4 module is loaded.
--
Trond Myklebust
Linux NFS client maintainer, PrimaryData
[email protected]
On Thu, Nov 13, 2014 at 01:52:09PM -0500, Trond Myklebust wrote:
> On Thu, Nov 13, 2014 at 12:57 PM, Steve Dickson <[email protected]> wrote:
> > On 11/12/2014 05:42 PM, Trond Myklebust wrote:
> >>>> NFS v4.0, 4.1, and 4.2 are all part of the same module, though. Is there a way to analyze modules and determine what is compiled in?
> >>> > Maybe come up with some global bit field could be used?
> >>> > Each bit signifies a minor version is enabled...
> >>> >
> >> No. This means that mount.nfs now suddenly needs to know the names of
> >> the NFS modules and how to load them before it calls mount() just so
> >> that it knows which parameters to try. This is a rathole we don't want
> >> to explore...
> > I don't think mount.nfs needs to know any names... Just
> > a file /proc/fs/nfs/mount that tells mount.nfs where
> > to start the negotiation....
> >
>
> The kernel does not have that information until the NFSv4 module is loaded.
I still don't get it. All it needs to know is an upper bound--that
could be a single compile-time constant. Is there any reason not to
build that number into the main nfs module?
--b.
On Thu, Nov 13, 2014 at 2:02 PM, J. Bruce Fields <[email protected]> wrote:
> On Thu, Nov 13, 2014 at 01:52:09PM -0500, Trond Myklebust wrote:
>> On Thu, Nov 13, 2014 at 12:57 PM, Steve Dickson <[email protected]> wrote:
>> > On 11/12/2014 05:42 PM, Trond Myklebust wrote:
>> >>>> NFS v4.0, 4.1, and 4.2 are all part of the same module, though. Is there a way to analyze modules and determine what is compiled in?
>> >>> > Maybe come up with some global bit field could be used?
>> >>> > Each bit signifies a minor version is enabled...
>> >>> >
>> >> No. This means that mount.nfs now suddenly needs to know the names of
>> >> the NFS modules and how to load them before it calls mount() just so
>> >> that it knows which parameters to try. This is a rathole we don't want
>> >> to explore...
>> > I don't think mount.nfs needs to know any names... Just
>> > a file /proc/fs/nfs/mount that tells mount.nfs where
>> > to start the negotiation....
>> >
>>
>> The kernel does not have that information until the NFSv4 module is loaded.
>
> I still don't get it. All it needs to know is an upper bound--that
> could be a single compile-time constant. Is there any reason not to
> build that number into the main nfs module?
>
Firstly, the main nfs module isn't preloaded either.
Secondly, that's a layering violation. The main nfs module has no
business knowing anything about the sub-modules other than how to load
them when needed. If I want to recompile my NFSv4 module to add
NFSv4.2 support, then I shouldn't have to recompile the entire
contents of my nfs directory.
--
Trond Myklebust
Linux NFS client maintainer, PrimaryData
[email protected]
On Thu, Nov 13, 2014 at 02:26:20PM -0500, Trond Myklebust wrote:
> On Thu, Nov 13, 2014 at 2:02 PM, J. Bruce Fields <[email protected]> wrote:
> > On Thu, Nov 13, 2014 at 01:52:09PM -0500, Trond Myklebust wrote:
> >> On Thu, Nov 13, 2014 at 12:57 PM, Steve Dickson <[email protected]> wrote:
> >> > On 11/12/2014 05:42 PM, Trond Myklebust wrote:
> >> >>>> NFS v4.0, 4.1, and 4.2 are all part of the same module, though. Is there a way to analyze modules and determine what is compiled in?
> >> >>> > Maybe come up with some global bit field could be used?
> >> >>> > Each bit signifies a minor version is enabled...
> >> >>> >
> >> >> No. This means that mount.nfs now suddenly needs to know the names of
> >> >> the NFS modules and how to load them before it calls mount() just so
> >> >> that it knows which parameters to try. This is a rathole we don't want
> >> >> to explore...
> >> > I don't think mount.nfs needs to know any names... Just
> >> > a file /proc/fs/nfs/mount that tells mount.nfs where
> >> > to start the negotiation....
> >> >
> >>
> >> The kernel does not have that information until the NFSv4 module is loaded.
> >
> > I still don't get it. All it needs to know is an upper bound--that
> > could be a single compile-time constant. Is there any reason not to
> > build that number into the main nfs module?
> >
>
> Firstly, the main nfs module isn't preloaded either.
That doesn't sound like a big deal.
> Secondly, that's a layering violation. The main nfs module has no
> business knowing anything about the sub-modules other than how to load
> them when needed. If I want to recompile my NFSv4 module to add
> NFSv4.2 support, then I shouldn't have to recompile the entire
> contents of my nfs directory.
You don't have to, you just have to mount with -oversion=4.2 in that
case.
The compile-time constant here is just a default starting point for
negotation.
As long as there's no stable kernel API, and end users don't routinely
load modules from the future, the nfs module seems like a reasonable
enough place to store the default minorversion.
--b.
On Thu, Nov 13, 2014 at 2:55 PM, J. Bruce Fields <[email protected]> wrote:
> On Thu, Nov 13, 2014 at 02:26:20PM -0500, Trond Myklebust wrote:
>> On Thu, Nov 13, 2014 at 2:02 PM, J. Bruce Fields <[email protected]> wrote:
>> > On Thu, Nov 13, 2014 at 01:52:09PM -0500, Trond Myklebust wrote:
>> >> On Thu, Nov 13, 2014 at 12:57 PM, Steve Dickson <[email protected]> wrote:
>> >> > On 11/12/2014 05:42 PM, Trond Myklebust wrote:
>> >> >>>> NFS v4.0, 4.1, and 4.2 are all part of the same module, though. Is there a way to analyze modules and determine what is compiled in?
>> >> >>> > Maybe come up with some global bit field could be used?
>> >> >>> > Each bit signifies a minor version is enabled...
>> >> >>> >
>> >> >> No. This means that mount.nfs now suddenly needs to know the names of
>> >> >> the NFS modules and how to load them before it calls mount() just so
>> >> >> that it knows which parameters to try. This is a rathole we don't want
>> >> >> to explore...
>> >> > I don't think mount.nfs needs to know any names... Just
>> >> > a file /proc/fs/nfs/mount that tells mount.nfs where
>> >> > to start the negotiation....
>> >> >
>> >>
>> >> The kernel does not have that information until the NFSv4 module is loaded.
>> >
>> > I still don't get it. All it needs to know is an upper bound--that
>> > could be a single compile-time constant. Is there any reason not to
>> > build that number into the main nfs module?
>> >
>>
>> Firstly, the main nfs module isn't preloaded either.
>
> That doesn't sound like a big deal.
>
>> Secondly, that's a layering violation. The main nfs module has no
>> business knowing anything about the sub-modules other than how to load
>> them when needed. If I want to recompile my NFSv4 module to add
>> NFSv4.2 support, then I shouldn't have to recompile the entire
>> contents of my nfs directory.
>
> You don't have to, you just have to mount with -oversion=4.2 in that
> case.
>
> The compile-time constant here is just a default starting point for
> negotation.
>
> As long as there's no stable kernel API, and end users don't routinely
> load modules from the future, the nfs module seems like a reasonable
> enough place to store the default minorversion.
>
It is reasonable if and only if your process can load modules and read
procfs, neither of which are guaranteed in all situations where we may
want to use mount.nfs.
IOW: no...
--
Trond Myklebust
Linux NFS client maintainer, PrimaryData
[email protected]
On Thu, Nov 13, 2014 at 03:22:20PM -0500, Trond Myklebust wrote:
> On Thu, Nov 13, 2014 at 2:55 PM, J. Bruce Fields <[email protected]> wrote:
> > On Thu, Nov 13, 2014 at 02:26:20PM -0500, Trond Myklebust wrote:
> >> Secondly, that's a layering violation. The main nfs module has no
> >> business knowing anything about the sub-modules other than how to load
> >> them when needed. If I want to recompile my NFSv4 module to add
> >> NFSv4.2 support, then I shouldn't have to recompile the entire
> >> contents of my nfs directory.
> >
> > You don't have to, you just have to mount with -oversion=4.2 in that
> > case.
> >
> > The compile-time constant here is just a default starting point for
> > negotation.
> >
> > As long as there's no stable kernel API, and end users don't routinely
> > load modules from the future, the nfs module seems like a reasonable
> > enough place to store the default minorversion.
> >
>
> It is reasonable if and only if your process can load modules and read
> procfs, neither of which are guaranteed in all situations where we may
> want to use mount.nfs.
Yeah, OK, so if we have to assume access to not much more than the mount
syscall then I give up. (I guess the only way to let the nfs module
decide the default in that case would be to let the kernel do more of
the negotation?)
--b.
On Nov 12, 2014, at 12:10 PM, Steve Dickson <[email protected]> wrote:
>=20
>=20
> On 11/12/2014 10:37 AM, Chuck Lever wrote:
>>>> But I do see your point of not having to recompile mount
>>>>>> when we want to change the default minor release so
>>>>>> how that default is set is the question... Maybe
>>>>>> an environment variable??
>>>>=20
>>>> That's still something that requires a user or sysadmin action, and =
it
>>>> wouldn't really play well with autofs and its ilk. As Marie =
Antoinette
>>>> would say: "Let them edit /etc/nfsmount.conf=94
>> Fwiw: I thought this was the whole point of nfsmount.conf.
>> We should be able to rev nfs-utils while preserving the
>> administrator=92s locally chosen default settings.
>>=20
>> +1 for using /etc/nfsmount.conf for this.
>>=20
> The reason the files exists is when we move the default
> version from v3 to v4 there would be away move the=20
> default back to v3 for legacy servers. Way=20
> way to move back from the future, if you will ;-)
> I never thought we would used it to go forward,
> just back...=20
>=20
> The problem with setting defaults in nfsmount.conf
> its not scalable especially in very large=20
> installations.
I=92m not sure what that means.
There are three sections of the configuration file: one
is for global behavior, right? What makes adding a
DefaultMinorVers here a problem?
If there is a scalability problem, shouldn=92t we try to
address that?
> I get it that distros can set
> it during installation, but that becomes error prone
> when different nfs-utils are used with different=20
> kernels. I think we should be more dynamic=20
>=20
> I think we barrow a paradigm from the server. On
> server the supported protocols are in /proc/fs/nfsd/verions
> that rpc.nfsd reads. We should do the same thing on the
> client.=20
>=20
> The kernel will tell mount.nfs where to start the negotiation.=20
>=20
> This will stop mount.nfs for needing to be compiled=20
> on minor version updates, plus it solves the problem
> of different kernels having different protocols enabled.
>=20
> I think this approach much more dynamic and it
> seems to work on the server side...=20
>=20
> steved.
>=20
>=20
--
Chuck Lever
chuck[dot]lever[at]oracle[dot]com
On 11/13/2014 10:07 AM, Chuck Lever wrote:
>> The problem with setting defaults in nfsmount.conf
>> > its not scalable especially in very large
>> > installations.
> I?m not sure what that means.
>
> There are three sections of the configuration file: one
> is for global behavior, right? What makes adding a
> DefaultMinorVers here a problem?
Its not so much its difficult to do, its difficult to
manage especially when it comes to changing something
in a vary large installation.
>
> If there is a scalability problem, shouldn?t we try to
> address that?
I'm trying to avoid one... ;-)
I just think one should be able to install a new kernel
that supports a new minor version and have mount.nfs be
able to use the minor version w/out recompile or
editing some config file..
steved.
On 11/12/2014 10:28 AM, Trond Myklebust wrote:
> On Wed, Nov 12, 2014 at 10:10 AM, Steve Dickson <[email protected]> wrote:
>>
>>
>> On 11/12/2014 09:31 AM, Trond Myklebust wrote:
>>>> My point is I don't think we need another variable, say
>>>>> DefaultMinVers, that defines the minor version of v4. I'm
>>>>> thinking that's its overkill and adds unnecessary complexity.
>>>>>
>>> I never said we do.
>> Ok... I misunderstood...
>>
>>>
>>> I think we're in agreement mostly; the only point where I see
>>> disagreement is when Defaultvers is unset.
>>> My position is that in that situation, we don't know what starting
>>> point to use for minor version negotiation, and so we should just
>>> default to minor version 0: if the sysadmin want a different default,
>>> then the answer is to set Defaultvers...
>> Gotta... and there is a disagreement... I saying we make the
>> default the highest supported minor version. With the
>> Linux client and server that's v4.2. So when no option is
>> given and Defaultvers is not set, try 4.2, then 4.1 and
>> then 4.0 and finally v3.
>
> Only for Linux 3.11 and newer, and only if they enable CONFIG_NFS_V4_2
> / CONFIG_NFSD_V4_SECURITY_LABEL.
Being dynamic is never easy! ;-)
The server has /proc/fs/nfsd/versions file that defines the
supported versions. Maybe we can come up with something
on the client that would tell what protocols are supported...
>
> Unless we want to have different defaults for older kernels, this sort
> of implies that we're moving in the direction of coupling the
> nfs-utils releases more tightly to the kernel version. I'm neutral to
> that, but I do want to call it out.
>
>> But I do see your point of not having to recompile mount
>> when we want to change the default minor release so
>> how that default is set is the question... Maybe
>> an environment variable??
>
> That's still something that requires a user or sysadmin action, and it
> wouldn't really play well with autofs and its ilk. As Marie Antoinette
> would say: "Let them edit /etc/nfsmount.conf"
Clever.. :-)
>
>> One down side of being the aggressive with minor version
>> negotiation is legacy servers (aka AIX). Today we
>> don't negotiate well with those types of servers...
>> Its not our fault, but is a problem...
>
> Is this because they don't implement that part of RFC3530?
The server returns the wrong type of error when a v4
mount is done so the mount fails instead of rolling back
to v3.
steved.
> On Nov 11, 2014, at 8:39 AM, Benjamin Coddington <[email protected]> wro=
te:
>=20
> I will update mount.nfs so the default version is 4.1.
Hi Ben, can you explicitly test your change with NFSv4.0-only servers? Thank=
s!
> I have two quick
> questions on desired behavior:
>=20
> o Should mounts that do not specify a minor version be upgraded to the de=
fault minor version?
>=20
> For example, should 'mount -overs=3D4' turn into 'mount -overs4.1', if the=
> current default is 4.1?
>=20
>=20
> o If 'yes' to the above, should mount auto-retry decrementing minor
> versions if EPROTONOSUPPORT?
>=20
> For example, 'mount -overs=3D4' with a default of 4.2 would attempt: 4.2,
> then 4.1, then 4.0.
>=20
> Ben
> --
> To unsubscribe from this list: send the line "unsubscribe linux-nfs" in
> the body of a message to [email protected]
> More majordomo info at http://vger.kernel.org/majordomo-info.html
On Tue, 11 Nov 2014, Chuck Lever wrote:
>
> > On Nov 11, 2014, at 8:39 AM, Benjamin Coddington <[email protected]> wrote:
> >
> > I will update mount.nfs so the default version is 4.1.
>
> Hi Ben, can you explicitly test your change with NFSv4.0-only servers? Thanks!
Hi Chuck,
I've posted a first-pass:
http://marc.info/?l=linux-nfs&m=141625339013956&w=2
I've tested against rpc.nfsd with '-N 4.1', and fallback to v4.0 seems
to work fine.
Ben
On Nov 17, 2014, at 2:47 PM, Benjamin Coddington <[email protected]> wrote:
>
> On Tue, 11 Nov 2014, Chuck Lever wrote:
>
>>
>>> On Nov 11, 2014, at 8:39 AM, Benjamin Coddington <[email protected]> wrote:
>>>
>>> I will update mount.nfs so the default version is 4.1.
>>
>> Hi Ben, can you explicitly test your change with NFSv4.0-only servers? Thanks!
>
> Hi Chuck,
>
> I've posted a first-pass:
> http://marc.info/?l=linux-nfs&m=141625339013956&w=2
>
> I've tested against rpc.nfsd with '-N 4.1', and fallback to v4.0 seems
> to work fine.
Thanks!
--
Chuck Lever
chuck[dot]lever[at]oracle[dot]com
Here's a quick summary of where the threads ended up:
- Everyone agrees that if a specific minor version is specified, only
that version should be attempted.
- On the issue of minor version omission, the positions are:
1) vers=4 means try 4.1, 4.0.
Steve D
Boaz
Ben C
2) vers=4 means try 4.0 only.
Andros
Anna
Frank
3) vers=4 means
- if conf file defaultvers=4.1, try 4.1, 4.0.
- else if defaultvers not set try 4.0 only.
Trond
Anyone else want to weigh in? Trond's position can also count towards
the second position because we should consider the case where the config
file is not used or turned off in the build. I think I could just add a
bit to the config file that switches between 1 and 2, something like
"usebestversion", which defaults to position 2. That would allow a
distro to use the first behavior if they chose.
Ben
On Tue, 11 Nov 2014, Benjamin Coddington wrote:
> I will update mount.nfs so the default version is 4.1. I have two quick
> questions on desired behavior:
>
> o Should mounts that do not specify a minor version be upgraded to the
> default minor version?
>
> For example, should 'mount -overs=4' turn into 'mount -overs4.1', if the
> current default is 4.1?
>
>
> o If 'yes' to the above, should mount auto-retry decrementing minor
> versions if EPROTONOSUPPORT?
>
> For example, 'mount -overs=4' with a default of 4.2 would attempt: 4.2,
> then 4.1, then 4.0.
>
> Ben
> --
> To unsubscribe from this list: send the line "unsubscribe linux-nfs" in
> the body of a message to [email protected]
> More majordomo info at http://vger.kernel.org/majordomo-info.html
>
On Wed, Nov 12, 2014 at 8:09 AM, Benjamin Coddington
<[email protected]> wrote:
> Here's a quick summary of where the threads ended up:
>
> - Everyone agrees that if a specific minor version is specified, only
> that version should be attempted.
>
> - On the issue of minor version omission, the positions are:
> 1) vers=4 means try 4.1, 4.0.
> Steve D
> Boaz
> Ben C
So where does the number 4.1 come from here? Is that a compile option?
That means we would need to recompile every time someone wants to bump
the version number to a new default.
> 2) vers=4 means try 4.0 only.
> Andros
> Anna
> Frank
>
> 3) vers=4 means
> - if conf file defaultvers=4.1, try 4.1, 4.0.
> - else if defaultvers not set try 4.0 only.
> Trond
>
> Anyone else want to weigh in? Trond's position can also count towards
> the second position because we should consider the case where the config
> file is not used or turned off in the build. I think I could just add a
> bit to the config file that switches between 1 and 2, something like
> "usebestversion", which defaults to position 2. That would allow a
> distro to use the first behavior if they chose.
>
> Ben
>
>
> On Tue, 11 Nov 2014, Benjamin Coddington wrote:
>
>> I will update mount.nfs so the default version is 4.1. I have two quick
>> questions on desired behavior:
>>
>> o Should mounts that do not specify a minor version be upgraded to the
>> default minor version?
>>
>> For example, should 'mount -overs=4' turn into 'mount -overs4.1', if the
>> current default is 4.1?
>>
>>
>> o If 'yes' to the above, should mount auto-retry decrementing minor
>> versions if EPROTONOSUPPORT?
>>
>> For example, 'mount -overs=4' with a default of 4.2 would attempt: 4.2,
>> then 4.1, then 4.0.
>>
>> Ben
>> --
>> To unsubscribe from this list: send the line "unsubscribe linux-nfs" in
>> the body of a message to [email protected]
>> More majordomo info at http://vger.kernel.org/majordomo-info.html
>>
> --
> To unsubscribe from this list: send the line "unsubscribe linux-nfs" in
> the body of a message to [email protected]
> More majordomo info at http://vger.kernel.org/majordomo-info.html
--
Trond Myklebust
Linux NFS client maintainer, PrimaryData
[email protected]
On Wed, 12 Nov 2014, Trond Myklebust wrote:
> On Wed, Nov 12, 2014 at 8:09 AM, Benjamin Coddington
> <[email protected]> wrote:
> > Here's a quick summary of where the threads ended up:
> >
> > - Everyone agrees that if a specific minor version is specified, only
> > that version should be attempted.
> >
> > - On the issue of minor version omission, the positions are:
> > 1) vers=4 means try 4.1, 4.0.
> > Steve D
> > Boaz
> > Ben C
>
> So where does the number 4.1 come from here? Is that a compile option?
> That means we would need to recompile every time someone wants to bump
> the version number to a new default.
Right now it is - one reason is that the version parsing code is not
very dynamic; I'll change that. Another reason is that mount.nfs
returns an error for invalid values of vers= instead of attempting them.
I should just change that as well since it doesn't match the behavior of
the the v# option which is always passed on to the kernel.
So mount.nfs will be version-impartial.
That resolves the case where the minor version is not specified and the
config file is not used/set: we must chose 0 for a minor version since
mount.nfs will have no other way to determine which minor version should
be used.
That's what I'll do unless there's any other objections. Thanks for
weighing in, everyone.
Ben
> > 2) vers=4 means try 4.0 only.
> > Andros
> > Anna
> > Frank
> >
> > 3) vers=4 means
> > - if conf file defaultvers=4.1, try 4.1, 4.0.
> > - else if defaultvers not set try 4.0 only.
> > Trond
> >
> > Anyone else want to weigh in? Trond's position can also count towards
> > the second position because we should consider the case where the config
> > file is not used or turned off in the build. I think I could just add a
> > bit to the config file that switches between 1 and 2, something like
> > "usebestversion", which defaults to position 2. That would allow a
> > distro to use the first behavior if they chose.
> >
> > Ben
> >
> >
> > On Tue, 11 Nov 2014, Benjamin Coddington wrote:
> >
> >> I will update mount.nfs so the default version is 4.1. I have two quick
> >> questions on desired behavior:
> >>
> >> o Should mounts that do not specify a minor version be upgraded to the
> >> default minor version?
> >>
> >> For example, should 'mount -overs=4' turn into 'mount -overs4.1', if the
> >> current default is 4.1?
> >>
> >>
> >> o If 'yes' to the above, should mount auto-retry decrementing minor
> >> versions if EPROTONOSUPPORT?
> >>
> >> For example, 'mount -overs=4' with a default of 4.2 would attempt: 4.2,
> >> then 4.1, then 4.0.
> >>
> >> Ben
> >> --
> >> To unsubscribe from this list: send the line "unsubscribe linux-nfs" in
> >> the body of a message to [email protected]
> >> More majordomo info at http://vger.kernel.org/majordomo-info.html
> >>
> > --
> > To unsubscribe from this list: send the line "unsubscribe linux-nfs" in
> > the body of a message to [email protected]
> > More majordomo info at http://vger.kernel.org/majordomo-info.html
>
>
>
> --
> Trond Myklebust
>
> Linux NFS client maintainer, PrimaryData
>
> [email protected]
>