From: Neil Brown Subject: Re: [nfs-utils PATCH] retry on EPERM from NFSv4 mount attempt Date: Wed, 25 Nov 2009 08:51:22 +1100 Message-ID: <20091125085122.316f4eb3@notabene.brown> References: <19211.7054.291514.185591@notabene.brown> <4B0BEDDB.1010203@RedHat.com> <20091124205616.GB29856@fieldses.org> Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Cc: Steve Dickson , linux-nfs@vger.kernel.org To: "J. Bruce Fields" Return-path: Received: from cantor2.suse.de ([195.135.220.15]:33311 "EHLO mx2.suse.de" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S933460AbZKXVtW (ORCPT ); Tue, 24 Nov 2009 16:49:22 -0500 In-Reply-To: <20091124205616.GB29856@fieldses.org> Sender: linux-nfs-owner@vger.kernel.org List-ID: On Tue, 24 Nov 2009 15:56:16 -0500 "J. Bruce Fields" wrote: > On Tue, Nov 24, 2009 at 09:29:47AM -0500, Steve Dickson wrote: > > > So I think we need to fall back on EPERM as well. See below. > > I already posted this patch on the v4 mailing list > > http://linux-nfs.org/pipermail/nfsv4/2009-November/011595.html > > but it got shot down... at least that's how I interpreted the > > responses... Thanks for the reference ... clearly I am not keeping up with my nfs mailing lists.... > > > > But I do thing we need this, since there are so many server > > that will simple break if we don't... Agreed? Agreed that we certainly need something. We cannot expect people to reconfigure their servers because they installed new software on the client. > > My position is that servers should either a) turn off NFSv4 or b) add > a pseudoroot, and that we should modify initscripts to make this > harder to screw up. In the ideal world, yes. Maybe this is best done in the kernel? Can we synthesis an RPC-protocol-not-supported error if and NFSv4 request arrives from a client for which no pseudo-root is configured? > > (For now (without automatic pseudoroot creation) we should by default > be running rpc.nfsd with -N 4; and adding the v4 support should be > something administrators do when they add a pseudoroot.) Hind sight is 20/20 they say. We probably should have done this, but I think it is now too late to do anything useful in the init scripts. > > ((If this is really totally unfeasible, then I should quickly cue up a > revert for the patch I have queued for 2.6.33 which changes this error > again, to SERVERFAULT....)) Maybe - maybe not. The situation on the client is that for a command that has traditionally always performed a v3 or (before that) a v2 mount, we are now trying a v4 mount. I see that v4 attempt as opportunistic. If anything goes wrong I think it is reasonable to go back to "the old way". So I think this piece of code in mount.nfs should retry on any error at all, so it would not matter whether you change again to SERVERFAULT. But I think the best fix for the kernel is to get nfsd4_proc_compound to return RPC_PROG_MISMATCH if there is no pseudo root, and then get svc_process_common to handle this and fake up appropriate min/max version numbers. Thanks, NeilBrown