On Mon, 2012-11-19 at 13:11 -0500, Chuck Lever wrote:
> On Nov 19, 2012, at 11:24 AM, "Myklebust, Trond" <Trond.Myklebust@xxxxxxxxxx> wrote:
>
> > On Mon, 2012-11-19 at 11:14 -0500, Steve Dickson wrote:
> >>
> >> On 19/11/12 11:02, Myklebust, Trond wrote:
> >>> On Mon, 2012-11-19 at 10:58 -0500, Steve Dickson wrote:
> >>>>
> >>>> On 19/11/12 10:54, Myklebust, Trond wrote:
> >>>>> On Mon, 2012-11-19 at 10:43 -0500, Steve Dickson wrote:
> >>>>>> This patch will convert -o v4.1, vers=4.1 or nfsvers=4.1 into
> >>>>>> the corresponding "v4,minorversion=1", "vers=4,minorversion=1"
> >>>>>> or "nfsvers=4,minorversion=1" options.
> >>>>>>
> >>>>>
> >>>>> NACK.
> >>>>>
> >>>>> If you are going to do this, then please do it only for kernels that
> >>>>> don't support the "vers=4.1" syntax. i.e. anything older than Linux-3.4.
> >>>> This is the intention...
> >>>>
> >>>>>
> >>>>> We want to get rid of minorversion=x, not perpetuate it...
> >>>>>
> >>>> Understood... But that is not option in some worlds... ;-)
> >>>
> >>> Sure it is. The mount program can continue to parse minorversion= after
> >>> it is gone from the kernel and convert it into the vers=4.x syntax.
> >>>
> >> Basically what I'm doing now, with the exception of not adding
> >> the minorversion=1 options...
> >>
> >> BTW, there is a bug in the -o v4.1 current logic...
> >>
> >> mount -o v4.1 produces both "v4.1,vers=4,..." in the string that given
> >> to the kernel which does not seem right... I would assume just a "v4.1,.."
> >> should be pumped down..
> >
> > Yes. I remember seeing that in the Bakeathon tests... I agree that we
> > just need the vers=4.1. The extra 'vers=4' isn't harmful in that the
> > kernel won't interpret it as vers=4.0, but it would be nice to get rid
> > of it.
> >
> > Essentially, the plan is that some time in the future we will want to
> > have 'vers=4' be the 'auto-negotiate minor version' syntax, while
> > vers=4.x will be the 'use minor version x' syntax.
> > Of course, auto-negotiation should be driven by the 'mount' program,
> > which will be using the 'vers=4.x' syntax in the mount system call, for
> > various values of 'x', until it achieves success.
>
> Interesting. I assume you want "mount.nfs" to do this to allow some kind of auto-negotiation policy to be specified (say, via the mount command configuration file).
Right. I'd like to be able to set Defaultvers=4.1 in /etc/nfsmount.conf
and have it work.
> As a design precursor, can you speculate on how the mount command would go about negotiating the minor version? mount.nfs cannot use protocol versions advertised by rpcbind, for instance, and neither can a simple NULL request identify which minor versions are available on the server.
Note that the mount command should in any case not be relying on rpcbind
to decide whether or not the server supports NFSv4.
As for minor version negotiation, RFC3530 already tells you how to do
this: the client has to start with the highest version that it supports,
and then walk that number down until the server stops replying with
NFS4ERR_MINOR_VERS_MISMATCH.
Note that if you want to do this in userland before calling the mount
syscall, then the spec does allow you to "ping" the NFSv4 server with an
empty COMPOUND.
--
Trond Myklebust
Linux NFS client maintainer
NetApp
Trond.Myklebust@xxxxxxxxxx
www.netapp.com
��.n��������+%������w��{.n�����{��w��� jg��� �����ݢj����G���� ���j:+v���w�m������w�������h�����٥
