Return-Path: trond.myklebust@primarydata.com MIME-Version: 1.0 In-Reply-To: <54635BB5.1020702@RedHat.com> References: <5462608B.1090607@RedHat.com> <54635BB5.1020702@RedHat.com> Date: Wed, 12 Nov 2014 09:31:48 -0500 Message-ID: Subject: Re: mount default minor version behavior From: Trond Myklebust To: Steve Dickson Cc: Benjamin Coddington , Linux NFS Mailing List Content-Type: text/plain; charset=UTF-8 List-ID: On Wed, Nov 12, 2014 at 8:08 AM, Steve Dickson wrote: > > > On 11/11/2014 03:43 PM, Trond Myklebust wrote: >> On Tue, Nov 11, 2014 at 2:16 PM, Steve Dickson wrote: >>> >>> >>> On 11/11/2014 10:01 AM, Trond Myklebust wrote: >>>> One thing you should note when doing this: the current parser for >>>> /etc/nfsmount.conf does not support minor versions. I think it needs >>>> to, so that we can continue to use it to set defaults. >>> Well setting Nfsvers=4.1 will give you a v4.1 mounts (assuming >>> the server supports v4.1. but setting Defaultvers=4.1 does >>> give you a v4.0 mount, which will need to be fixed. >>> >>>> >>>> ...and to answer your questions above, I think that we should be able >>>> to specify a 'default nfsv4 minor version' in /etc/nfsmount.conf, and >>>> then negotiate down from there. >>>> IOW: extend the 'Defaultvers' and 'Nfsvers' options to support 4.0, >>>> 4.1, 4.2,.... >>> Well Defaultvers is a negotiation with the server, Nfsvers is not. >>> So when Nfsvers set set there is no negotiation, they get what is >>> set to (aka 3, 4, 4.0, 4.1, just like the command line). >>> >>> With Defaultvers its a negotiation so set it to highest >>> version and let it go... I'm not sure we need another >>> variable to complicate things... >>> >>>> >>>> The result should be that If I do 'mount -t nfs' with no '-overs' >>>> option, then we start at 4.1 (if that is the default in >>>> /etc/nfsmount.conf) and then try 4.0, 3, 2 in that order. >>>> If I do 'mount -t nfs -overs=4', then again consult /etc/nfsmount.conf; >>>> - if there is a default matching a v4 minor version, then start at >>>> that and negotiate down (but stop at 4.0). >>> Again, I'm thinking this type of complexity is not needed (especially >>> from a testing matrix point of view). >>> >>> besides, if someone is specifying a version on the command line, is most likely >>> they are not going to be using /etc/nfsmount.conf as all... >>> >>>> - if there is no default in /etc/nfsmount.conf, then perhaps assume a >>>> default of 0(????) >>> I'm thinking why not default to the better minor version?? 4.1 => 4.0 => 3 >> >> So at which minor version do you start? 4.10, 4.100?... > The highest one.... Set Defaultvers to the highest version > (including minor version) and then let the negotiations happen. > >> We don't want to have to recompile mount every time we add a new minor >> version in order to bump the maximum number, which is why I think we >> want to use /etc/nfsmount.conf and Defaultvers to define that (and >> assume '0' if undefined). > I agree. The fact that you can't set DefaultVers=4.2 and then > negotiated down to what both sides support (even if its v3) > is a problem and needs to be fixed. > > My point is I don't think we need another variable, say > DefaultMinVers, that defines the minor version of v4. I'm > thinking that's its overkill and adds unnecessary complexity. > I never said we do. I think we're in agreement mostly; the only point where I see disagreement is when Defaultvers is unset. My position is that in that situation, we don't know what starting point to use for minor version negotiation, and so we should just default to minor version 0: if the sysadmin want a different default, then the answer is to set Defaultvers... Cheers Trond -- Trond Myklebust Linux NFS client maintainer, PrimaryData trond.myklebust@primarydata.com