On Mon, 2012-11-19 at 13:39 -0500, Chuck Lever wrote:
> On Nov 19, 2012, at 1:29 PM, "Myklebust, Trond" <Trond.Myklebust@xxxxxxxxxx> wrote:
>
> > 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.
>
> I see: not an NFSv4 NULL, but an NFSv4 COMPOUND that has no operations. That carries a compound header, which would have the minor version number in it.
Right. Section 16.2.4 of RFC5661 would appear to allow the server to
return the following errors in the case of an empty COMPOUND: NFS4_OK,
NFS4ERR_DELAY, NFS4ERR_MINOR_VERS_MISMATCH and NFS4ERR_SERVERFAULT.
The other errors shouldn't apply at all to a zero-op compound
(NFS4ERR_BADXDR, NFS4ERR_TOO_MANY_OPS, NFS4ERR_REP_TOO_BIG_TO_CACHE), or
should only apply if you have a non-empty optional tag argument
(NFS4ERR_BADCHAR, NFS4ERR_INVAL, NFS4ERR_REP_TOO_BIG,
NFS4ERR_REQ_TOO_BIG).
--
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�����٥
