From: Tom Talpey <tmtalpey@gmail.com>
To: Chuck Lever <chuck.lever@oracle.com>
Cc: 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: Thu, 19 Mar 2009 14:41:36 -0400 [thread overview]
Message-ID: <49c29203.85c2f10a.098d.17b5@mx.google.com> (raw)
In-Reply-To: <1FF921B7-4A44-49D7-8E01-1DAC5D18C1AB@oracle.com>
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.
next prev parent reply other threads:[~2009-03-19 18:42 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 [this message]
[not found] ` <49c29203.85c2f10a.098d.17b5-ATjtLOhZ0NVl57MIdRCFDg@public.gmane.org>
2009-03-20 11:55 ` Steve Dickson
2009-04-18 1:00 ` Kevin Constantine
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=49c29203.85c2f10a.098d.17b5@mx.google.com \
--to=tmtalpey@gmail.com \
--cc=SteveD@redhat.com \
--cc=bhalevy@panasas.com \
--cc=chuck.lever@oracle.com \
--cc=linux-nfs@vger.kernel.org \
/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