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

[Peter Staubach <staubach@redhat.com>]

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

Well, to the last section, that is an RPC error and not an
NFS error.  The RPC error, VERSMISMATCH, might be close, but
once again, is an RPC error and not an NFS error.

I don't think that an RPC error is correct to return if the
server is configured to support NFSv4.  It might not be
correctly configured and completely configured, but in
theory, it is supposed to support NFSv4.

I'd probably buy into the SERVERFAULT as the most logical error.

Doing something better is tough because of the way that exports
and the NFS service are managed as distinct things.  Perhaps if
the NFS service could detect that there were no NFSv4 exports,
then it could decline to register the NFSv4 service.  Then, some
of the RPC errors would make sense.

The layering in the current implementations seems to make things
more difficult than it does make them easy.  Just my opinion.

		ps