On Nov 12, 2014, at 12: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’m not sure what that means. There are three sections of the configuration file: one is for global behavior, right? What makes adding a DefaultMinorVers here a problem? If there is a scalability problem, shouldn’t we try to address that? > 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. > > -- Chuck Lever chuck[dot]lever[at]oracle[dot]com -- 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
