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

[Trond Myklebust <trond.myklebust@fys.uio.no>]

On Wed, 2009-11-25 at 09:22 +1100, Neil Brown wrote: 
> 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.

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