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@xxxxxxxxxxxxxxx
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 majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
