Re: [RFC PATCH V2] mount: Added the -o v4.1 mount option

["J. Bruce Fields" <bfields@fieldses.org>]

On Mon, Nov 19, 2012 at 07:04:10PM +0000, Myklebust, Trond wrote:
> On Mon, 2012-11-19 at 13:39 -0500, Chuck Lever wrote:
> > On Nov 19, 2012, at 1:29 PM, "Myklebust, Trond" <Trond.Myklebust@netapp.com> wrote:
> > > 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).

And, I just wanted to check because I hadn't thought about this before:
the Linux server does appear to handle 0-length compounds correctly.
(And there's a 4.0 pynfs test, COMP1, which checks that a server will
accept a zero-length compound, so anyone that's run pynfs should have
noticed if there server doesn't.)

--b.