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@xxxxxxxxxx>
wrote:
On Mar 19, 2009, at Mar 19, 2009, 12:34 PM, Muntz, Daniel wrote:
-----Original Message-----
From: Steve Dickson [mailto:SteveD@xxxxxxxxxx]
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
--
To unsubscribe from this list: send the line "unsubscribe linux-nfs" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
