Re: mount default minor version behavior

[Steve Dickson <SteveD@redhat.com>]

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@redhat.com> 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.