Re: [nfs-utils PATCH] retry on EPERM from NFSv4 mount attempt

[Neil Brown <neilb@suse.de>]

On Tue, 24 Nov 2009 16:58:29 -0500
Peter Staubach <staubach@redhat.com> 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