On Tue, 24 Nov 2009 15:56:16 -0500 "J. Bruce Fields" <bfields@xxxxxxxxxxxx> 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 -- To unsubscribe from this list: send the line "unsubscribe linux-nfs" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
