On 11/12/2014 03:17 PM, Anna Schumaker wrote: > On 11/12/2014 01:41 PM, Trond Myklebust wrote: >> 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. >> >> > NFS v4.0, 4.1, and 4.2 are all part of the same module, though. Is there a way to analyze modules and determine what is compiled in? Maybe come up with some global bit field could be used? Each bit signifies a minor version is enabled... 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
