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@xxxxxxxxxx> 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. -- To unsubscribe from this list: send the line "unsubscribe linux-nfs" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
