On 11/12/2014 10:37 AM, Chuck Lever wrote: >>> But I do see your point of not having to recompile mount >>> >> when we want to change the default minor release so >>> >> how that default is set is the question... Maybe >>> >> an environment variable?? >> > >> > That's still something that requires a user or sysadmin action, and it >> > wouldn't really play well with autofs and its ilk. As Marie Antoinette >> > would say: "Let them edit /etc/nfsmount.conf” > Fwiw: I thought this was the whole point of nfsmount.conf. > We should be able to rev nfs-utils while preserving the > administrator’s locally chosen default settings. > > +1 for using /etc/nfsmount.conf for this. > The reason the files exists is when we move the default version from v3 to v4 there would be away move the default back to v3 for legacy servers. Way way to move back from the future, if you will ;-) I never thought we would used it to go forward, just back... The problem with setting defaults in nfsmount.conf its not scalable especially in very large installations. I get it that distros can set it during installation, but that becomes error prone when different nfs-utils are used with different kernels. I think we should be more dynamic I think we barrow a paradigm from the server. On server the supported protocols are in /proc/fs/nfsd/verions that rpc.nfsd reads. We should do the same thing on the client. The kernel will tell mount.nfs where to start the negotiation. This will stop mount.nfs for needing to be compiled on minor version updates, plus it solves the problem of different kernels having different protocols enabled. I think this approach much more dynamic and it seems to work on the server side... 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
