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.
NeilBrown
--
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
