All of lore.kernel.org
 help / color / mirror / Atom feed
From: Steve Dickson <SteveD@redhat.com>
To: Chuck Lever <chuck.lever@oracle.com>
Cc: Linux NFSv4 mailing list <nfsv4@linux-nfs.org>,
	Linux NFS Mailing List <linux-nfs@vger.kernel.org>
Subject: Re: The next step: nfsvers=4
Date: Thu, 19 Mar 2009 12:50:35 -0400	[thread overview]
Message-ID: <49C277DB.70401@RedHat.com> (raw)
In-Reply-To: <855593AD-7541-443F-BA92-491EC32FEDFB@oracle.com>



Chuck Lever wrote:
> On Mar 19, 2009, at Mar 19, 2009, 12:34 PM, Muntz, Daniel wrote:
>>> -----Original Message-----
>>> From: Steve Dickson [mailto:SteveD@redhat.com]
>>> Sent: Thursday, March 19, 2009 9:18 AM
>>> To: linux NFS Mailing list
>>> Subject: The next step: nfsvers=4
>>>
>>> As I see it, the next step to seamlessly move to V4 as the
>>> default is to make 'mount -o nfsvers=4' actually do a v4 mount...
>>>
>>> There are two obvious place we can make this change.
>>> In the kernel and/or in the mount command...
>>>
>>> Looking at the kernel, since v3 and v4 truly two different
>>> file systems its seems a bit late for the nfs_get_sb() to all
>>> of sudden have to change file system type. Meaning when
>>> nfs_get_sb() sees the "nfsvers=4" somehow it would have to
>>> back out and call nfs4_get_sb(), which obviously is a bit hacky....
>>>
>>> Now I guess we could have one nfs_get_sb() for both v3 and v4.
>>> Where the nfs_get_sb() could peek into the options data to
>>> see which version is needed. This would also mean the mount
>>> command would always have to set a version so when the "nfsvers="
>>> options is not set, the kernel would know which version to use.
>>> Again, this feels a bit hacky as well but doable...
>>>
>>> At least to me, what seems like the best option is to have
>>> the mount.nfs binary early on intercept "nfsvers=4" option
>>> and then change the fs_type to "nfs4", which would allow
>>> everything to "trickle down" as it does today... Again to me,
>>> that seem like the least intrusive way to do it...
>>>
>>> Comments? Is there other ways?
> 
> Having the mount.nfs command translate sounds like a pretty easy thing
> to prototype.
Yes.. I agree...

> 
>> Whichever way it's done, if v4 becomes the default, don't forget to also
>> make the default behavior be that the system will fall back and try a v3
>> mount if v4 isn't available.  Otherwise you'll break a huge percentage
>> of your user base.  Of course then you also have to deal with the
>> semantics of how to specifify "only v4" vs. "try v4 first and fall
>> back".
> 
> Today, specifying vers=3 means "I want vers=3 or nothing".  Not
> specifying any version means the mount command can choose which version
> to use based on what both sides support.
> 
> If no vers= option is specified, I don't think it would be difficult for
> the text-based mount command to try a "nfs4" mount first, and if that
> fails try an "nfs" mount.
> 
> Steve, would you like me to provide a prototype mount.nfs command that
> handles this?
Well I was thinking more of lets walk before we run... meaning... lets just get the
'nfsvers=4' working and accepted. Then deal with the v4/v3/v2 fall back in the
next patch set... 

As you say... the prototype looks to be pretty easy... so let me take a crack at
it... besides... you are making some good progress with IPV6 code... I don't
think this should get in the way of that...

steved.


steved.

  reply	other threads:[~2009-03-19 16:50 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 [this message]
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
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=49C277DB.70401@RedHat.com \
    --to=steved@redhat.com \
    --cc=chuck.lever@oracle.com \
    --cc=linux-nfs@vger.kernel.org \
    --cc=nfsv4@linux-nfs.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 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.