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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.