From: Kevin Constantine <Kevin.Constantine-FfNkGbSheRGpB8w63BLUukEOCMrvLtNR@public.gmane.org>
To: Tom Talpey <tmtalpey@gmail.com>
Cc: Chuck Lever <chuck.lever@oracle.com>,
Benny Halevy <bhalevy@panasas.com>,
Steve Dickson <SteveD@redhat.com>,
Linux NFS Mailing List <linux-nfs@vger.kernel.org>
Subject: Re: The next step: nfsvers=4
Date: Fri, 17 Apr 2009 18:00:07 -0700 [thread overview]
Message-ID: <49E92617.4080504@disney.com> (raw)
In-Reply-To: <49c29203.85c2f10a.098d.17b5-ATjtLOhZ0NVl57MIdRCFDg@public.gmane.org>
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
next prev parent reply other threads:[~2009-04-18 1:00 UTC|newest]
Thread overview: 13+ messages / expand[flat|nested] mbox.gz Atom feed top
2009-03-19 16:18 The next step: nfsvers=4 Steve Dickson
[not found] ` <49C2704F.5050303-AfCzQyP5zfLQT0dZR+AlfA@public.gmane.org>
2009-03-19 16:34 ` Muntz, Daniel
[not found] ` <7A24DF798E223B4C9864E8F92E8C93EC026043D3-hX7t0kiaRRpT+ZUat5FNkAK/GNPrWCqfQQ4Iyu8u01E@public.gmane.org>
2009-03-19 16:43 ` Chuck Lever
2009-03-19 16:50 ` Steve Dickson
2009-03-19 17:33 ` Benny Halevy
2009-03-19 18:13 ` Chuck Lever
2009-03-19 18:41 ` Tom Talpey
[not found] ` <49c29203.85c2f10a.098d.17b5-ATjtLOhZ0NVl57MIdRCFDg@public.gmane.org>
2009-03-20 11:55 ` Steve Dickson
2009-04-18 1:00 ` Kevin Constantine [this message]
2009-03-20 11:50 ` Steve Dickson
[not found] ` <49C382F1.6080205-AfCzQyP5zfLQT0dZR+AlfA@public.gmane.org>
2009-03-20 18:50 ` Muntz, Daniel
2009-04-18 1:12 ` Kevin Constantine
2009-03-19 16:43 ` Steve Dickson
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=49E92617.4080504@disney.com \
--to=kevin.constantine-ffnkgbshergpb8w63bluukeocmrvltnr@public.gmane.org \
--cc=SteveD@redhat.com \
--cc=bhalevy@panasas.com \
--cc=chuck.lever@oracle.com \
--cc=linux-nfs@vger.kernel.org \
--cc=tmtalpey@gmail.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox