Return-Path: Anna.Schumaker@netapp.com Message-ID: <5463C066.8030205@Netapp.com> Date: Wed, 12 Nov 2014 15:17:42 -0500 From: Anna Schumaker MIME-Version: 1.0 To: Trond Myklebust , Steve Dickson CC: Chuck Lever , Benjamin Coddington , Linux NFS Mailing List Subject: Re: mount default minor version behavior References: <5462608B.1090607@RedHat.com> <54635BB5.1020702@RedHat.com> <5463787A.7080404@RedHat.com> <43A888DD-6114-48FC-AE99-DBE6BBF19A7B@oracle.com> <5463A282.8060803@RedHat.com> In-Reply-To: Content-Type: text/plain; charset="utf-8" List-ID: On 11/12/2014 01:41 PM, Trond Myklebust wrote: > On Wed, Nov 12, 2014 at 1:10 PM, Steve Dickson 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? Anna