From: Peter Staubach Subject: Re: [nfs-utils PATCH] retry on EPERM from NFSv4 mount attempt Date: Tue, 24 Nov 2009 17:29:28 -0500 Message-ID: <4B0C5E48.8020600@redhat.com> References: <19211.7054.291514.185591@notabene.brown> <4B0BEDDB.1010203@RedHat.com> <20091124205616.GB29856@fieldses.org> <20091125085122.316f4eb3@notabene.brown> <4B0C5705.6030608@redhat.com> <20091125092227.77735d5a@notabene.brown> Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Cc: "J. Bruce Fields" , Steve Dickson , linux-nfs@vger.kernel.org To: Neil Brown Return-path: Received: from mx1.redhat.com ([209.132.183.28]:63555 "EHLO mx1.redhat.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S933903AbZKXW3b (ORCPT ); Tue, 24 Nov 2009 17:29:31 -0500 In-Reply-To: <20091125092227.77735d5a-wvvUuzkyo1EYVZTmpyfIwg@public.gmane.org> Sender: linux-nfs-owner@vger.kernel.org List-ID: Neil Brown wrote: > On Tue, 24 Nov 2009 16:58:29 -0500 > Peter Staubach 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