On Wed, 2009-11-25 at 09:22 +1100, Neil Brown wrote: > On Tue, 24 Nov 2009 16:58:29 -0500 > Peter Staubach <staubach@xxxxxxxxxx> wrote: > > > I think that we might be better off in the long run by taking a > > step back and getting all of the plumbing right, instead of > > cluttering up things to have knowledge which they have no > > business knowing or worrying about. > > In principle, I completely agree. > > > > > > If the NFSv4 server gets a request which involves the root file > > handle and one has not been defined, then it should return the > > error that is defined by the protocol. What the client chooses > > to do with the error is up to it. > > There is no error for "root file handle has not been defined". > > The only errors available for PUTROOTFH are: > NFS4ERR_RESOURCE - which means "I'm exchausted after all the other > work you made me do" and shouldn't be returned for > the first op in a compound (that is an implied > restriction, not explicit). > NFS4ERR_SERVERFAULT which means something strange went wrong. This is > probably the closest, hence Bruce's recent patch to > use this error code. > NFS4ERR_WRONGSEC which means the security mechanism used by the > client isn't acceptable to the server. This is > certainly not usable in this context. > > So NFS4ERR_SERVERFAULT would be OK simply because it is a wildcard. > But RPC_PROG_MISMATCH, which means "I don't support that version of the > protocol" would also be correct in this case and it trivial for the > client to interpret. One response that the spec allows is to accept the PUTROOTFH, but to return either NFS4ERR_BADHANDLE or NFS4ERR_SERVERFAULT on any operation that attempts to use the resulting filehandle. Cheers Trond -- 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
