From: Kevin Constantine <Kevin.Constantine-FfNkGbSheRGpB8w63BLUukEOCMrvLtNR@public.gmane.org>
To: Steve Dickson <SteveD@redhat.com>
Cc: Chuck Lever <chuck.lever@oracle.com>,
Benny Halevy <bhalevy@panasas.com>,
Linux NFS Mailing List <linux-nfs@vger.kernel.org>
Subject: Re: The next step: nfsvers=4
Date: Fri, 17 Apr 2009 18:12:30 -0700 [thread overview]
Message-ID: <49E928FE.3060606@disney.com> (raw)
In-Reply-To: <49C382F1.6080205-AfCzQyP5zfLQT0dZR+AlfA@public.gmane.org>
Steve Dickson wrote:
> Chuck Lever wrote:
>> 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
> I would say ignore this particular option... since, in a sense, v4 give you this option
> by default due to delegations... but point well taken... The mapping of
> v3 to v4 and visa versa will have to be addressed... I would guess in the mount
> command...
>
>> 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?
> I think people just want things to work... so if they specify only UDP
> and the server supports V4, we give them V4/TCP. If they REALLY want
> UDP, they would have to specify 'nfsvers=3,udp'.
>
> Or, if there was an mount configuration file, they could specify the
> MAX_VERSION to be 3 and then -o udp mounts work as expected...
>
I would agree that things should just work as much as possible. I would
think that the options that aren't applicable should be ignored, and the
values that are known to be incorrect should be fixed if possible.
More likely than not, I care that my mount succeeds. Once that happens,
I begin to care how it succeeded, and can go figure out where I made a
mistake and how I ended up with v4/tcp when I really wanted udp and
didn't care which nfs version I use.
>>> 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.
I like the idea of having a file that allows me to specify or default
values, or acceptable ranges for the various mount options. I'd also
like to be able to specify overrideable options in the automount maps
where the right-most option wins.
-kevin
> The /etc/sysconfig/nfs is a distro only file... Meaning I know of only
> one distro that uses that file.. So I would tend to shy away from putting
> anything in that...
>
> steved.
> --
> 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:12 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
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 [this message]
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=49E928FE.3060606@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 \
/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