The next step: nfsvers=4

The next step: nfsvers=4

[Steve Dickson]

As I see it, the next step to seamlessly move to V4 as 
the default is to make 'mount -o nfsvers=4' actually 
do a v4 mount... 

There are two obvious place we can make this change.
In the kernel and/or in the mount command... 

Looking at the kernel, since v3 and v4 truly two different
file systems its seems a bit late for the nfs_get_sb()
to all of sudden have to change file system type. Meaning
when nfs_get_sb() sees the "nfsvers=4" somehow it would
have to back out and call nfs4_get_sb(), which obviously 
is a bit hacky.... 

Now I guess we could have one nfs_get_sb() for both v3 and v4.
Where the nfs_get_sb() could peek into the options data to
see which version is needed. This would also mean the mount 
command would always have to set a version so when the "nfsvers=" 
options is not set, the kernel would know which version to use.
Again, this feels a bit hacky as well but doable... 

At least to me, what seems like the best option is to have 
the mount.nfs binary early on intercept "nfsvers=4" option
and then change the fs_type to "nfs4", which would allow
everything to "trickle down" as it does today... Again to
me, that seem like the least intrusive way to do it...

Comments? Is there other ways?

steved.

 

RE: The next step: nfsvers=4

[Muntz, Daniel]

 

> -----Original Message-----
> From: Steve Dickson [mailto:SteveD@redhat.com] 
> Sent: Thursday, March 19, 2009 9:18 AM
> To: linux NFS Mailing list
> Subject: The next step: nfsvers=4
> 
> As I see it, the next step to seamlessly move to V4 as the 
> default is to make 'mount -o nfsvers=4' actually do a v4 mount... 
> 
> There are two obvious place we can make this change.
> In the kernel and/or in the mount command... 
> 
> Looking at the kernel, since v3 and v4 truly two different 
> file systems its seems a bit late for the nfs_get_sb() to all 
> of sudden have to change file system type. Meaning when 
> nfs_get_sb() sees the "nfsvers=4" somehow it would have to 
> back out and call nfs4_get_sb(), which obviously is a bit hacky.... 
> 
> Now I guess we could have one nfs_get_sb() for both v3 and v4.
> Where the nfs_get_sb() could peek into the options data to 
> see which version is needed. This would also mean the mount 
> command would always have to set a version so when the "nfsvers=" 
> options is not set, the kernel would know which version to use.
> Again, this feels a bit hacky as well but doable... 
> 
> At least to me, what seems like the best option is to have 
> the mount.nfs binary early on intercept "nfsvers=4" option 
> and then change the fs_type to "nfs4", which would allow 
> everything to "trickle down" as it does today... Again to me, 
> that seem like the least intrusive way to do it...
> 
> Comments? Is there other ways?

Whichever way it's done, if v4 becomes the default, don't forget to also
make the default behavior be that the system will fall back and try a v3
mount if v4 isn't available.  Otherwise you'll break a huge percentage
of your user base.  Of course then you also have to deal with the
semantics of how to specifify "only v4" vs. "try v4 first and fall
back".

> 
> steved.
> 
>  
> --
> To unsubscribe from this list: send the line "unsubscribe 
> linux-nfs" in the body of a message to 
> majordomo@vger.kernel.org More majordomo info at  
> http://vger.kernel.org/majordomo-info.html
> 

Re: The next step: nfsvers=4

[Chuck Lever]

On Mar 19, 2009, at Mar 19, 2009, 12:34 PM, Muntz, Daniel wrote:
>> -----Original Message-----
>> From: Steve Dickson [mailto:SteveD@redhat.com]
>> Sent: Thursday, March 19, 2009 9:18 AM
>> To: linux NFS Mailing list
>> Subject: The next step: nfsvers=4
>>
>> As I see it, the next step to seamlessly move to V4 as the
>> default is to make 'mount -o nfsvers=4' actually do a v4 mount...
>>
>> There are two obvious place we can make this change.
>> In the kernel and/or in the mount command...
>>
>> Looking at the kernel, since v3 and v4 truly two different
>> file systems its seems a bit late for the nfs_get_sb() to all
>> of sudden have to change file system type. Meaning when
>> nfs_get_sb() sees the "nfsvers=4" somehow it would have to
>> back out and call nfs4_get_sb(), which obviously is a bit hacky....
>>
>> Now I guess we could have one nfs_get_sb() for both v3 and v4.
>> Where the nfs_get_sb() could peek into the options data to
>> see which version is needed. This would also mean the mount
>> command would always have to set a version so when the "nfsvers="
>> options is not set, the kernel would know which version to use.
>> Again, this feels a bit hacky as well but doable...
>>
>> At least to me, what seems like the best option is to have
>> the mount.nfs binary early on intercept "nfsvers=4" option
>> and then change the fs_type to "nfs4", which would allow
>> everything to "trickle down" as it does today... Again to me,
>> that seem like the least intrusive way to do it...
>>
>> Comments? Is there other ways?

Having the mount.nfs command translate sounds like a pretty easy thing  
to prototype.

> Whichever way it's done, if v4 becomes the default, don't forget to  
> also
> make the default behavior be that the system will fall back and try  
> a v3
> mount if v4 isn't available.  Otherwise you'll break a huge percentage
> of your user base.  Of course then you also have to deal with the
> semantics of how to specifify "only v4" vs. "try v4 first and fall
> back".

Today, specifying vers=3 means "I want vers=3 or nothing".  Not  
specifying any version means the mount command can choose which  
version to use based on what both sides support.

If no vers= option is specified, I don't think it would be difficult  
for the text-based mount command to try a "nfs4" mount first, and if  
that fails try an "nfs" mount.

Steve, would you like me to provide a prototype mount.nfs command that  
handles this?

--
Chuck Lever
chuck[dot]lever[at]oracle[dot]com

Re: The next step: nfsvers=4

[Steve Dickson]

Chuck Lever wrote:
> On Mar 19, 2009, at Mar 19, 2009, 12:34 PM, Muntz, Daniel wrote:
>>> -----Original Message-----
>>> From: Steve Dickson [mailto:SteveD@redhat.com]
>>> Sent: Thursday, March 19, 2009 9:18 AM
>>> To: linux NFS Mailing list
>>> Subject: The next step: nfsvers=4
>>>
>>> As I see it, the next step to seamlessly move to V4 as the
>>> default is to make 'mount -o nfsvers=4' actually do a v4 mount...
>>>
>>> There are two obvious place we can make this change.
>>> In the kernel and/or in the mount command...
>>>
>>> Looking at the kernel, since v3 and v4 truly two different
>>> file systems its seems a bit late for the nfs_get_sb() to all
>>> of sudden have to change file system type. Meaning when
>>> nfs_get_sb() sees the "nfsvers=4" somehow it would have to
>>> back out and call nfs4_get_sb(), which obviously is a bit hacky....
>>>
>>> Now I guess we could have one nfs_get_sb() for both v3 and v4.
>>> Where the nfs_get_sb() could peek into the options data to
>>> see which version is needed. This would also mean the mount
>>> command would always have to set a version so when the "nfsvers="
>>> options is not set, the kernel would know which version to use.
>>> Again, this feels a bit hacky as well but doable...
>>>
>>> At least to me, what seems like the best option is to have
>>> the mount.nfs binary early on intercept "nfsvers=4" option
>>> and then change the fs_type to "nfs4", which would allow
>>> everything to "trickle down" as it does today... Again to me,
>>> that seem like the least intrusive way to do it...
>>>
>>> Comments? Is there other ways?
> 
> Having the mount.nfs command translate sounds like a pretty easy thing
> to prototype.
Yes.. I agree...

> 
>> Whichever way it's done, if v4 becomes the default, don't forget to also
>> make the default behavior be that the system will fall back and try a v3
>> mount if v4 isn't available.  Otherwise you'll break a huge percentage
>> of your user base.  Of course then you also have to deal with the
>> semantics of how to specifify "only v4" vs. "try v4 first and fall
>> back".
> 
> Today, specifying vers=3 means "I want vers=3 or nothing".  Not
> specifying any version means the mount command can choose which version
> to use based on what both sides support.
> 
> If no vers= option is specified, I don't think it would be difficult for
> the text-based mount command to try a "nfs4" mount first, and if that
> fails try an "nfs" mount.
> 
> Steve, would you like me to provide a prototype mount.nfs command that
> handles this?
Well I was thinking more of lets walk before we run... meaning... lets just get the
'nfsvers=4' working and accepted. Then deal with the v4/v3/v2 fall back in the
next patch set... 

As you say... the prototype looks to be pretty easy... so let me take a crack at
it... besides... you are making some good progress with IPV6 code... I don't
think this should get in the way of that...

steved.


steved.

Re: The next step: nfsvers=4

[Benny Halevy]

On Mar. 19, 2009, 18:43 +0200, Chuck Lever <chuck.lever@oracle.com> wrote:
> On Mar 19, 2009, at Mar 19, 2009, 12:34 PM, Muntz, Daniel wrote:
>>> -----Original Message-----
>>> From: Steve Dickson [mailto:SteveD@redhat.com]
>>> Sent: Thursday, March 19, 2009 9:18 AM
>>> To: linux NFS Mailing list
>>> Subject: The next step: nfsvers=4
>>>
>>> As I see it, the next step to seamlessly move to V4 as the
>>> default is to make 'mount -o nfsvers=4' actually do a v4 mount...
>>>
>>> There are two obvious place we can make this change.
>>> In the kernel and/or in the mount command...
>>>
>>> Looking at the kernel, since v3 and v4 truly two different
>>> file systems its seems a bit late for the nfs_get_sb() to all
>>> of sudden have to change file system type. Meaning when
>>> nfs_get_sb() sees the "nfsvers=4" somehow it would have to
>>> back out and call nfs4_get_sb(), which obviously is a bit hacky....
>>>
>>> Now I guess we could have one nfs_get_sb() for both v3 and v4.
>>> Where the nfs_get_sb() could peek into the options data to
>>> see which version is needed. This would also mean the mount
>>> command would always have to set a version so when the "nfsvers="
>>> options is not set, the kernel would know which version to use.
>>> Again, this feels a bit hacky as well but doable...
>>>
>>> At least to me, what seems like the best option is to have
>>> the mount.nfs binary early on intercept "nfsvers=4" option
>>> and then change the fs_type to "nfs4", which would allow
>>> everything to "trickle down" as it does today... Again to me,
>>> that seem like the least intrusive way to do it...
>>>
>>> Comments? Is there other ways?
> 
> Having the mount.nfs command translate sounds like a pretty easy thing  
> to prototype.
> 
>> Whichever way it's done, if v4 becomes the default, don't forget to  
>> also
>> make the default behavior be that the system will fall back and try  
>> a v3
>> mount if v4 isn't available.  Otherwise you'll break a huge percentage
>> of your user base.  Of course then you also have to deal with the
>> semantics of how to specifify "only v4" vs. "try v4 first and fall
>> back".
> 
> Today, specifying vers=3 means "I want vers=3 or nothing".  Not  
> specifying any version means the mount command can choose which  
> version to use based on what both sides support.
> 
> If no vers= option is specified, I don't think it would be difficult  
> for the text-based mount command to try a "nfs4" mount first, and if  
> that fails try an "nfs" mount.

Agreed.
That's pretty much what we planned to do in the future also
for minorversion=1, after discussing this also with Trond.
The principle was that the policy for choosing what versions
to try and in which order should be determined by the
user mode utilities since one can think of customers that would
only want to use nfsv4.1 for its exactly once semantics,
or others that would want to start with 4.0 and fall back
to 3 and 2 since trying 4.1 might break their servers, etc.

I think that if no version is specified all versions that
the client supports should be tried, highest first.
Otherwise mount.nfs should try only the specified version.

For implementing more complex policies, maybe we can extend
the command syntax to accept a range and/or an ordered list
of versions to try.

Benny

> 
> Steve, would you like me to provide a prototype mount.nfs command that  
> handles this?
> 
> --
> Chuck Lever
> chuck[dot]lever[at]oracle[dot]com
> --
> To unsubscribe from this list: send the line "unsubscribe linux-nfs" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: The next step: nfsvers=4

[Chuck Lever]

On Mar 19, 2009, at Mar 19, 2009, 1:33 PM, Benny Halevy wrote:
> On Mar. 19, 2009, 18:43 +0200, Chuck Lever <chuck.lever@oracle.com>  
> wrote:
>> On Mar 19, 2009, at Mar 19, 2009, 12:34 PM, Muntz, Daniel wrote:
>>>> -----Original Message-----
>>>> From: Steve Dickson [mailto:SteveD@redhat.com]
>>>> Sent: Thursday, March 19, 2009 9:18 AM
>>>> To: linux NFS Mailing list
>>>> Subject: The next step: nfsvers=4
>>>>
>>>> As I see it, the next step to seamlessly move to V4 as the
>>>> default is to make 'mount -o nfsvers=4' actually do a v4 mount...
>>>>
>>>> There are two obvious place we can make this change.
>>>> In the kernel and/or in the mount command...
>>>>
>>>> Looking at the kernel, since v3 and v4 truly two different
>>>> file systems its seems a bit late for the nfs_get_sb() to all
>>>> of sudden have to change file system type. Meaning when
>>>> nfs_get_sb() sees the "nfsvers=4" somehow it would have to
>>>> back out and call nfs4_get_sb(), which obviously is a bit hacky....
>>>>
>>>> Now I guess we could have one nfs_get_sb() for both v3 and v4.
>>>> Where the nfs_get_sb() could peek into the options data to
>>>> see which version is needed. This would also mean the mount
>>>> command would always have to set a version so when the "nfsvers="
>>>> options is not set, the kernel would know which version to use.
>>>> Again, this feels a bit hacky as well but doable...
>>>>
>>>> At least to me, what seems like the best option is to have
>>>> the mount.nfs binary early on intercept "nfsvers=4" option
>>>> and then change the fs_type to "nfs4", which would allow
>>>> everything to "trickle down" as it does today... Again to me,
>>>> that seem like the least intrusive way to do it...
>>>>
>>>> Comments? Is there other ways?
>>
>> Having the mount.nfs command translate sounds like a pretty easy  
>> thing
>> to prototype.
>>
>>> Whichever way it's done, if v4 becomes the default, don't forget to
>>> also
>>> make the default behavior be that the system will fall back and try
>>> a v3
>>> mount if v4 isn't available.  Otherwise you'll break a huge  
>>> percentage
>>> of your user base.  Of course then you also have to deal with the
>>> semantics of how to specifify "only v4" vs. "try v4 first and fall
>>> back".
>>
>> Today, specifying vers=3 means "I want vers=3 or nothing".  Not
>> specifying any version means the mount command can choose which
>> version to use based on what both sides support.
>>
>> If no vers= option is specified, I don't think it would be difficult
>> for the text-based mount command to try a "nfs4" mount first, and if
>> that fails try an "nfs" mount.
>
> Agreed.
> That's pretty much what we planned to do in the future also
> for minorversion=1, after discussing this also with Trond.
> The principle was that the policy for choosing what versions
> to try and in which order should be determined by the
> user mode utilities since one can think of customers that would
> only want to use nfsv4.1 for its exactly once semantics,
> or others that would want to start with 4.0 and fall back
> to 3 and 2 since trying 4.1 might break their servers, etc.
>
> I think that if no version is specified all versions that
> the client supports should be tried, highest first.
> Otherwise mount.nfs should try only the specified version.

One nit is that the set of mount options supported by nfs4 is  
different than the set supported by nfs.  clientaddr= is supported by  
nfs4, but not by nfs, for example.  I believe that nocto is not  
supported by nfs4.  The mountproto option is only supported by nfs.

If no vers= is specified and only NFSv4 is available on the server,  
but something like "nocto" shows up on the command line mount options,  
do we:

a) fail the mount, or
b) ignore the nocto option

a) seems like the least surprising behavior.

What about "proto=udp" ?  Linux supports UDP for NFSv4, though other  
server implementations probably don't.  If that's specified on a mount  
command line without a vers= option, what version should we choose?

> For implementing more complex policies, maybe we can extend
> the command syntax to accept a range and/or an ordered list
> of versions to try.

Steve mentioned /etc/default/nfs on Solaris.  I could see /etc/ 
sysconfig/nfs on Linux containing a couple of lines defining the range  
of allowable NFS versions, if we think this is necessary.  This is a  
simple pre-existing file, and has little potential for introducing  
negative side-effects.

--
Chuck Lever
chuck[dot]lever[at]oracle[dot]com

Re: The next step: nfsvers=4

[Tom Talpey]

At 02:13 PM 3/19/2009, Chuck Lever wrote:
>On Mar 19, 2009, at Mar 19, 2009, 1:33 PM, Benny Halevy wrote:
>> I think that if no version is specified all versions that
>> the client supports should be tried, highest first.
>> Otherwise mount.nfs should try only the specified version.
>
>One nit is that the set of mount options supported by nfs4 is  
>different than the set supported by nfs.  clientaddr= is supported by  
>nfs4, but not by nfs, for example.  I believe that nocto is not  
>supported by nfs4.  The mountproto option is only supported by nfs.
>
>If no vers= is specified and only NFSv4 is available on the server,  
>but something like "nocto" shows up on the command line mount options,  
>do we:
>
>a) fail the mount, or
>b) ignore the nocto option
>
>a) seems like the least surprising behavior.

I think the "sloppy" option might be relevant here too.

While we're on the subject of sloppy, what about the automounter?
It has always been an issue to deploy automounter maps which are
shared by diverse client populations - there are significant issues
for older Linux clients, and newer Solaris ones for that matter, with
NFSv4.

I would strongly suggest touching and/or changing as few options as
possible, and paying close attention to the results with legacy or
generic configurations on new kernels. The more lenient, the better
IMO, except where specific options require specific actions.

Tom.

Re: The next step: nfsvers=4

[Steve Dickson]

Tom Talpey wrote:
> 
> I would strongly suggest touching and/or changing as few options as
> possible, and paying close attention to the results with legacy or
> generic configurations on new kernels. The more lenient, the better
> IMO, except where specific options require specific actions.
I agree with this... Being "backwards compatible" is imperative.
And allowing people to configure things to best fit their 
environment is something else we should maintain and possibly 
improve on...

steved.   

Re: The next step: nfsvers=4

[Kevin Constantine]

Tom Talpey wrote:
> At 02:13 PM 3/19/2009, Chuck Lever wrote:
>> On Mar 19, 2009, at Mar 19, 2009, 1:33 PM, Benny Halevy wrote:
>>> I think that if no version is specified all versions that
>>> the client supports should be tried, highest first.
>>> Otherwise mount.nfs should try only the specified version.
>> One nit is that the set of mount options supported by nfs4 is  
>> different than the set supported by nfs.  clientaddr= is supported by  
>> nfs4, but not by nfs, for example.  I believe that nocto is not  
>> supported by nfs4.  The mountproto option is only supported by nfs.
>>
>> If no vers= is specified and only NFSv4 is available on the server,  
>> but something like "nocto" shows up on the command line mount options,  
>> do we:
>>
>> a) fail the mount, or
>> b) ignore the nocto option
>>
>> a) seems like the least surprising behavior.
> 
> I think the "sloppy" option might be relevant here too.
> 
> While we're on the subject of sloppy, what about the automounter?
> It has always been an issue to deploy automounter maps which are
> shared by diverse client populations - there are significant issues
> for older Linux clients, and newer Solaris ones for that matter, with
> NFSv4.
> 

I ran into this very situation today which caused me to go back through 
the archive and find this thread.  Hopefully it isn't too late to add my 
two cents.

I want to begin testing nfsv4 in our environment, we rely heavily on 
autofs, and have a mixed OS environment, and some servers support v4, 
while others don't.

Most clients should continue to mount with v3, while a few select test 
machines should mount with v4 if the server supports it.

OSX and (i think) Solaris seem to use fstype=nfs and [nfs]vers=2,3,4 to 
specify the nfs version.  Linux on the other hand, requires that I set 
fstype=nfs4, and will fail to mount if [nfs]vers is present.

If nfsvers was just ignored or better yet, was honored (if I set 
fstype=nfs, and nfsvers=4, I don't really care that you change fstype to 
nfs4 on me under the covers), it would eliminate one hurdle in the quest 
for a unified automount map (at least in our environment).

-kevin

> I would strongly suggest touching and/or changing as few options as
> possible, and paying close attention to the results with legacy or
> generic configurations on new kernels. The more lenient, the better
> IMO, except where specific options require specific actions.
> 
> Tom.
> 
> --
> To unsubscribe from this list: send the line "unsubscribe linux-nfs" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: The next step: nfsvers=4

[Steve Dickson]

Chuck Lever wrote:
> If no vers= is specified and only NFSv4 is available on the server, but
> something like "nocto" shows up on the command line mount options, do we:
> 
> a) fail the mount, or
> b) ignore the nocto option
I would say ignore this particular option... since, in a sense, v4 give you this option
by default due to delegations... but point well taken... The mapping of
v3 to v4 and visa versa will have to be addressed... I would guess in the mount
command...  
 
> 
> a) seems like the least surprising behavior.
> 
> What about "proto=udp" ?  Linux supports UDP for NFSv4, though other
> server implementations probably don't.  If that's specified on a mount
> command line without a vers= option, what version should we choose?
I think people just want things to work... so if they specify only UDP
and the server supports V4, we give them V4/TCP. If they REALLY want 
UDP, they would have to specify 'nfsvers=3,udp'.

Or, if there was an mount configuration file, they could specify the
MAX_VERSION to be 3 and then -o udp mounts work as expected...

> 
>> For implementing more complex policies, maybe we can extend
>> the command syntax to accept a range and/or an ordered list
>> of versions to try.
> 
> Steve mentioned /etc/default/nfs on Solaris.  I could see
> /etc/sysconfig/nfs on Linux containing a couple of lines defining the
> range of allowable NFS versions, if we think this is necessary.  This is
> a simple pre-existing file, and has little potential for introducing
> negative side-effects.
The /etc/sysconfig/nfs is a distro only file... Meaning I know of only 
one distro that uses that file.. So I would tend to shy away from putting
anything in that... 

steved.

RE: The next step: nfsvers=4

[Muntz, Daniel]

 

> -----Original Message-----
> From: Steve Dickson [mailto:SteveD@redhat.com] 
> Sent: Friday, March 20, 2009 4:50 AM
> To: Chuck Lever
> Cc: Benny Halevy; Linux NFS Mailing List
> Subject: Re: The next step: nfsvers=4
> 
> Chuck Lever wrote:
> > If no vers= is specified and only NFSv4 is available on the server, 
> > but something like "nocto" shows up on the command line 
> mount options, do we:
> > 
> > a) fail the mount, or
> > b) ignore the nocto option
> I would say ignore this particular option... since, in a 
> sense, v4 give you this option by default due to 
> delegations... but point well taken... The mapping of
> v3 to v4 and visa versa will have to be addressed... I would 
> guess in the mount command...  
>  
> > 
> > a) seems like the least surprising behavior.
> > 
> > What about "proto=udp" ?  Linux supports UDP for NFSv4, 
> though other 
> > server implementations probably don't.  If that's specified 
> on a mount 
> > command line without a vers= option, what version should we choose?
> I think people just want things to work... so if they specify 
> only UDP and the server supports V4, we give them V4/TCP. If 
> they REALLY want UDP, they would have to specify 'nfsvers=3,udp'.

But, and this is a poor example, they REALLY want v4 and UDP?  There
should be consistency in the way rules are applied.  If specifying
vers=x requires the mount to match version x exactly, then imho, proto=y
should only succeed with protocol y.  There should be a way for the user
to specify exactly what they want, and fail if they can't have it.
Similarly, if someone specifies sec=krb5p, you wouldn't want to fall
back to sec=sys :-)

> 
> Or, if there was an mount configuration file, they could 
> specify the MAX_VERSION to be 3 and then -o udp mounts work 
> as expected...
> 
> > 
> >> For implementing more complex policies, maybe we can extend the 
> >> command syntax to accept a range and/or an ordered list of 
> versions 
> >> to try.
> > 
> > Steve mentioned /etc/default/nfs on Solaris.  I could see 
> > /etc/sysconfig/nfs on Linux containing a couple of lines 
> defining the 
> > range of allowable NFS versions, if we think this is 
> necessary.  This 
> > is a simple pre-existing file, and has little potential for 
> > introducing negative side-effects.
> The /etc/sysconfig/nfs is a distro only file... Meaning I 
> know of only one distro that uses that file.. So I would tend 
> to shy away from putting anything in that... 
> 
> steved.
> --
> To unsubscribe from this list: send the line "unsubscribe 
> linux-nfs" in the body of a message to 
> majordomo@vger.kernel.org More majordomo info at  
> http://vger.kernel.org/majordomo-info.html
> 

Re: The next step: nfsvers=4

[Kevin Constantine]

Steve Dickson wrote:
> Chuck Lever wrote:
>> If no vers= is specified and only NFSv4 is available on the server, but
>> something like "nocto" shows up on the command line mount options, do we:
>>
>> a) fail the mount, or
>> b) ignore the nocto option
> I would say ignore this particular option... since, in a sense, v4 give you this option
> by default due to delegations... but point well taken... The mapping of
> v3 to v4 and visa versa will have to be addressed... I would guess in the mount
> command...  
>  
>> a) seems like the least surprising behavior.
>>
>> What about "proto=udp" ?  Linux supports UDP for NFSv4, though other
>> server implementations probably don't.  If that's specified on a mount
>> command line without a vers= option, what version should we choose?
> I think people just want things to work... so if they specify only UDP
> and the server supports V4, we give them V4/TCP. If they REALLY want 
> UDP, they would have to specify 'nfsvers=3,udp'.
> 
> Or, if there was an mount configuration file, they could specify the
> MAX_VERSION to be 3 and then -o udp mounts work as expected...
> 

I would agree that things should just work as much as possible.  I would 
think that the options that aren't applicable should be ignored, and the 
  values that are known to be incorrect should be fixed if possible. 
More likely than not, I care that my mount succeeds.  Once that happens, 
I begin to care how it succeeded, and can go figure out where I made a 
mistake and how I ended up with v4/tcp when I really wanted udp and 
didn't care which nfs version I use.

>>> For implementing more complex policies, maybe we can extend
>>> the command syntax to accept a range and/or an ordered list
>>> of versions to try.
>> Steve mentioned /etc/default/nfs on Solaris.  I could see
>> /etc/sysconfig/nfs on Linux containing a couple of lines defining the
>> range of allowable NFS versions, if we think this is necessary.  This is
>> a simple pre-existing file, and has little potential for introducing
>> negative side-effects.

I like the idea of having a file that allows me to specify or default 
values, or acceptable ranges for the various mount options.  I'd also 
like to be able to specify overrideable options in the automount maps 
where the right-most option wins.

-kevin

> The /etc/sysconfig/nfs is a distro only file... Meaning I know of only 
> one distro that uses that file.. So I would tend to shy away from putting
> anything in that... 
> 
> steved.
> --
> To unsubscribe from this list: send the line "unsubscribe linux-nfs" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: The next step: nfsvers=4

[Steve Dickson]

Muntz, Daniel wrote:
>  
> 
>> -----Original Message-----
>> From: Steve Dickson [mailto:SteveD@redhat.com] 
>> Sent: Thursday, March 19, 2009 9:18 AM
>> To: linux NFS Mailing list
>> Subject: The next step: nfsvers=4
>>
>> As I see it, the next step to seamlessly move to V4 as the 
>> default is to make 'mount -o nfsvers=4' actually do a v4 mount... 
>>
>> There are two obvious place we can make this change.
>> In the kernel and/or in the mount command... 
>>
>> Looking at the kernel, since v3 and v4 truly two different 
>> file systems its seems a bit late for the nfs_get_sb() to all 
>> of sudden have to change file system type. Meaning when 
>> nfs_get_sb() sees the "nfsvers=4" somehow it would have to 
>> back out and call nfs4_get_sb(), which obviously is a bit hacky.... 
>>
>> Now I guess we could have one nfs_get_sb() for both v3 and v4.
>> Where the nfs_get_sb() could peek into the options data to 
>> see which version is needed. This would also mean the mount 
>> command would always have to set a version so when the "nfsvers=" 
>> options is not set, the kernel would know which version to use.
>> Again, this feels a bit hacky as well but doable... 
>>
>> At least to me, what seems like the best option is to have 
>> the mount.nfs binary early on intercept "nfsvers=4" option 
>> and then change the fs_type to "nfs4", which would allow 
>> everything to "trickle down" as it does today... Again to me, 
>> that seem like the least intrusive way to do it...
>>
>> Comments? Is there other ways?
> 
> Whichever way it's done, if v4 becomes the default, don't forget to also
> make the default behavior be that the system will fall back and try a v3
> mount if v4 isn't available.  Otherwise you'll break a huge percentage
> of your user base.  Of course then you also have to deal with the
> semantics of how to specifify "only v4" vs. "try v4 first and fall
> back".
No worries... falling back to v3/v2 will be the will definitely
happen before the switch is made... 

This was this is reason I'm pushing for a mount configuration file.
So the semantics of which version is or is not tried can be defined locally...

steved.