I believe this is the commit what is needed:

commit f980298853d9b12a222421342418732f65883c30
Author: Benjamin Coddington <bcodding>
Date:   Mon Dec 8 15:51:07 2014 -0500

    mount.nfs: configurable minor version defaults

Maybe some more...

Moving to v4.1 will also improved state recovery via test_stateid.

I'm in favor of doing this.  In fact, at this point we should consider 4.2.

4.1 and 4.2 are quite mature at this point.

This would allow users to get new features (pnfs, labeled NFS, fallocate, eventually server-side copy) without the need for changing the configuration on all their clients.

The v4.0 to v4.1 transition isn't like the v3 to v4.0 transition.  There should be no user visible changes, just some new features.  Also, the client will automatically negotiate back down to 4.0 if the server doesn't support 4.1.

So we should be able to upgrade automatically without disruption to users.

So I think the only risk is bugs: under the covers it's a big change to the protocol, and although overall I think 4.1 is probably in better shape than 4.0, there's always a risk that a user will encounter a new bug on upgrade.  (The 4.1 to 4.2 upgrade is much smaller and lower-risk.)

On balance I think it's worth at least seriously considering.

NetApp is also in favor of v4.1 as the default mount protocol. NetApp is committed to NFSv4.1, NetApp QA has been focusing much more on NFSv4.1 testing, and less on NFSv4.0. NFSv4.1 looks to be in better shape than NFSv4.0 WRT the NetApp filers. NetApp has focused performance work on NFSv4.1 where testing has shown that for many workloads, NFSv4.1 performs as well as and sometimes better than NFSv3.

(In reply to Andy Adamson from comment #4)
> NetApp is also in favor of v4.1 as the default mount protocol. NetApp is
> committed to NFSv4.1, NetApp QA has been focusing much more on NFSv4.1
> testing, and less on NFSv4.0. NFSv4.1 looks to be in better shape than
> NFSv4.0 WRT the NetApp filers. NetApp has focused performance work on
> NFSv4.1 where testing has shown that for many workloads, NFSv4.1 performs as
> well as and sometimes better than NFSv3.

Thanks for the feedback.

Would you have any objection to a default of 4.2?

It looks to me like the client implementaiton is sufficiently mature (it's just 4.1 plus some small features, so that's not surprising), and if NetApp wants to be more cautious it can disable 4.2 by default on the server side and let the client negotiate down.

There corresponding server bz 
    https://bugzilla.redhat.com/show_bug.cgi?id=1181310

I agree with starting the mounting process at 4.2... If
we are going to change it we might as well make
it the latest and greatest!

Weighing in from the PrimaryData perspective, we'd be much happier with a default of NFSv4.2 since our product has functional dependencies that require our customers to use NFSv4.2.

I agree that it should not be a problem to negotiate down from NFSv4.2; the basic NFSv4 protocol has an explicit prescription for how this should be done.

When specifying an incorrect nfs version, the warning message has changed as following.

As the upstream version also acts the same way, maybe it's not a big issue.

[root@hp-dl380eg8-03 ~]# rpm -q nfs-utils
nfs-utils-1.3.0-0.33.el7.x86_64
[root@hp-dl380eg8-03 ~]# mount.nfs localhost:/export_test/ /mnt/mnt_test/ -o vers=23
mount.nfs: parsing error on 'vers=' option         <<<<<<<<<<< Previously

[root@hp-dl380eg8-03 ~]# echo $?
32
[root@hp-dl380eg8-03 ~]#
[root@hp-dl380eg8-03 ~]# 
[root@hp-dl380eg8-03 ~]# rpm -Uvh nfs-utils-1.3.0-0.34.el7.x86_64.rpm &>/dev/null
[root@hp-dl380eg8-03 ~]# rpm -q nfs-utils
nfs-utils-1.3.0-0.34.el7.x86_64
[root@hp-dl380eg8-03 ~]# mount.nfs localhost:/export_test/ /mnt/mnt_test/ -o vers=23
mount.nfs: mount system call failed                <<<<<<<<<<<< Currently
[root@hp-dl380eg8-03 ~]# echo $?
32
[root@hp-dl380eg8-03 ~]# 
[root@hp-dl380eg8-03 ~]# ./nfs-utils/utils/mount/mount.nfs localhost:/export_test/ /mnt/mnt_test/ -o vers=23
mount.nfs: mount system call failed                <<<<<<<<<<<<< Upstream also
[root@hp-dl380eg8-03 ~]# echo $?
32
[root@hp-dl380eg8-03 ~]#

It has be decided, through testing at this year's connectathon,
the default v4 minor version should default to v1 not v2

(In reply to Steve Dickson from comment #26)
> It has be decided, through testing at this year's connectathon,
> the default v4 minor version should default to v1 not v2

Never mind... I forgot about bug 1435901

(In reply to Andy Adamson from comment #4)
> NetApp is also in favor of v4.1 as the default mount protocol. NetApp is
> committed to NFSv4.1, NetApp QA has been focusing much more on NFSv4.1
> testing, and less on NFSv4.0. NFSv4.1 looks to be in better shape than
> NFSv4.0 WRT the NetApp filers. NetApp has focused performance work on
> NFSv4.1 where testing has shown that for many workloads, NFSv4.1 performs as
> well as and sometimes better than NFSv3.

Andy, there's a Netapp server-side issue here with the 4.1 default:

In our testing we found ACLs failed on upgrading to a development RHEL7 version with a 4.1 default.  Turns out that's because the filer we were testing against was configured to support ACLs over 4.0 but not over 4.1.

That's a silly configuration, but apparently the Netapp filer allows it, and if we made that mistake, no doubt our users will too.  And from the user's point of view, it's going to be painful tracking down the failure to this obscure filer setting.

I'm told filers have similar per-minorversion settings for delegations and other features, which is silly.

If we're going to switch to 4.1 mid-RHEL7, then we need the move to be as seamless as possible.  We don't want random unrelated features turned off on upgrade.

Is there anyone at Netapp we can talk to about fixing this?

*** This bug has been marked as a duplicate of bug 1435901 ***