Bug 1375259 - NFSv4.1 as default NFS mount protocol
Summary: NFSv4.1 as default NFS mount protocol
Keywords:
Status: CLOSED DUPLICATE of bug 1435901
Alias: None
Product: Red Hat Enterprise Linux 7
Classification: Red Hat
Component: nfs-utils
Version: 7.4
Hardware: All
OS: Linux
high
medium
Target Milestone: rc
: ---
Assignee: Steve Dickson
QA Contact: Yongcheng Yang
Milan Navratil
URL:
Whiteboard:
Depends On: 1406885
Blocks: 1385242
TreeView+ depends on / blocked
 
Reported: 2016-09-12 14:53 UTC by Andy Adamson
Modified: 2018-09-17 15:10 UTC (History)
12 users (show)

Fixed In Version: nfs-utils-1.3.0-0.34
Doc Type: Release Note
Doc Text:
NFSv4.1 is now the default NFS mount protocol Prior to this update, NFSv4.0 was the default NFS mount protocol. NFSv4.1 provides significant feature improvements over NFSv4.0, such as sessions, pNFS, parallel OPENs, and session trunking. With this update, NFSv4.1 is the default NFS mount protocol. If you have already specified the mount protocol minor version, this update causes no change in behavior. This update causes a change in behavior if you have specified NFSv4 without a specific minor version, provided the server supports NFSv4.1. If the server only supports NFSv4.0, the mount remains a NFSv4.0 mount. You can retain the original behavior by specifying `0` as the minor version: * on the mount command line, * in the `/etc/fstab` file, * or in the `/etc/nfsmount.conf` file.
Clone Of:
Environment:
Last Closed: 2017-06-09 15:00:08 UTC


Attachments (Terms of Use)


Links
System ID Priority Status Summary Last Updated
Red Hat Product Errata RHBA-2017:2233 normal SHIPPED_LIVE nfs-utils bug fix and enhancement update 2017-08-01 18:19:33 UTC
Red Hat Bugzilla 1404617 None CLOSED mount.nfs fall back to version 3 when specifying "nfsvers=4" since nfs-utils-1.3.0-0.34.el7 2019-09-19 12:27:56 UTC
Red Hat Bugzilla 1406885 None CLOSED server supports labeled NFS by default 2019-09-19 12:27:56 UTC
Red Hat Bugzilla 1450447 None CLOSED [netapp] filer need to enable v4.1-acl otherwise nfs4_getfacl get failed as NFSv4.1 as default now 2019-09-19 12:27:56 UTC

Internal Links: 1404617 1406885 1450447

Description Andy Adamson 2016-09-12 14:53:31 UTC
Description of problem:
This is a feature request.
Currently, NFSv4.0 is the default NFS mount protocol. NFSv4.1 has been in the field long enough, and has significant feature improvements over NFSv4.0 such as sessions, pNFS, parallel OPENs, and session trunking that we are requesting NFSv4.1 to become the default NFS mount protocol.


Version-Release number of selected component (if applicable):


How reproducible:


Steps to Reproduce:
1.
2.
3.

Actual results:


Expected results:


Additional info:

Comment 1 Steve Dickson 2016-09-12 15:16:52 UTC
I believe this is the commit what is needed:

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

    mount.nfs: configurable minor version defaults

Maybe some more...

Comment 2 Steve Dickson 2016-09-19 14:43:26 UTC
Moving to v4.1 will also improved state recovery via test_stateid.

Comment 3 J. Bruce Fields 2016-10-21 16:29:19 UTC
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.

Comment 4 Andy Adamson 2016-10-28 20:05:03 UTC
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.

Comment 5 J. Bruce Fields 2016-10-28 20:35:58 UTC
(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.

Comment 6 Steve Dickson 2016-11-21 17:14:26 UTC
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!

Comment 7 Trond Myklebust 2016-12-07 23:21:28 UTC
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.

Comment 11 Yongcheng Yang 2016-12-20 05:29:45 UTC
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 ~]#

Comment 26 Steve Dickson 2017-05-02 17:57:57 UTC
It has be decided, through testing at this year's connectathon,
the default v4 minor version should default to v1 not v2

Comment 27 Steve Dickson 2017-05-02 18:04:28 UTC
(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

Comment 28 J. Bruce Fields 2017-05-12 21:00:24 UTC
(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?

Comment 30 Steve Dickson 2017-06-09 15:00:08 UTC

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


Note You need to log in before you can comment on or make changes to this bug.