Re: mount default minor version behavior

[Steve Dickson <SteveD@redhat.com>]

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... 

steved.