Sorry for the delayed response, I took some time off... On 11/24/2009 09:29 AM, Steve Dickson wrote: > > > On 11/23/2009 06:32 PM, Neil Brown wrote: >> >> Hi, >> I recently packaged nfs-utils 1.2.1 for openSUSE and fairly quickly >> got a bug report - "-o nfsvers=3" was needed to mount NFSv3 >> filesystems. >> >> mount.nfs in 1.2.1 will first try a v4 mount but will fall-back to v3 >> if it gets ENOENT. This works fine. >> However for kernel prior to 2.6.25, you don't get ENOENT, you get >> EPERM. >> In that case the fall-back to v3 doesn't happen and you get a failure >> to mount. >> >> 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... > > But I do thing we need this, since there are so many server > that will simple break if we don't... Agreed? There appears to be a consensus that we need to do something but no agreement on what.... I believe the options are: 1) Start servers with '-N 4' when there is no root configured. * The problem I see with this is, in the event v4 support is wanted its yet another configuration knob that has to be turned, basically making it more difficult for people use v4. 2) Change the kernel to return NFS4ERR_SERVERFAULT when there is no root configured. * I see this is yet another errno the mounting code has to deal with.. We are up to two errnos, do we really want to add a third? Neither one of these solutions deal with legacy servers or move the "v4 technology" forward... IMHO... So what I suggest we do is: 1) Finish the dynamic pseudo root support asap, since all this goes away when that support exists. 2) We commit the "roll back to v3 on EPERM errors" and we draw a line in the sand saying if a server does not return one of these errors on v4 mounts when there is a not a root configured, the server is broken and needs to be fix. Point, these are the only two errnos that will cause a v3 roll back. * My only concern is how we are going to work with non-linux servers and how much extra network trace will this cause during automount storms... But in the end, I think we will have to go with the "roll back on EPERM errors" patch, because there is simply no way a mount command can be released in an enterprise environment that is not backward compatible with existing servers. Consensus? steved. -- 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
