Linux NFS development
 help / color / mirror / Atom feed
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

  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