On Wed, Nov 12, 2014 at 1:10 PM, Steve Dickson <SteveD@xxxxxxxxxx> wrote: > > > 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... > The NFS client modules are loaded on demand. The kernel will therefore not actually know the capabilities until we attempt the mount. -- Trond Myklebust Linux NFS client maintainer, PrimaryData trond.myklebust@xxxxxxxxxxxxxxx -- 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
