Re: [RFC] Making mount_nfs to attempt NFSv4 before NFSv3 and NFSv2?
Alexander Leidinger wrote: > Rick Macklem wrote: [stuff snipped] > > > > Other than testing diskless NFS root file systems, I do not have a > > strong opinion w.r.t. whether the default should change. > > > > If the default stays as NFSv3, a fallback to NFSv4 could be done, which > > would handle the NFSv4 only server case. (No one uses NFSv2 any more, > > so the fallback to NFSv2 is almost irrelevant, imho.) > > As you particiate in interoperability tests, would it make sense to > check how those other implementations handle this case? I naively > assume you have some contacts or a mailinglist you could use for that. Not sure what you are asking, but... The only other client I am familiar with is the Linux one. It does NFSv4, then NFSv3 (I think they have dropped NFSv2 support). Linux also does handle NFSv4 root file systems. The other clients I know of (VMware and Windows) do not paticipate in the IETF Working group's interoperability testing, unfortunately. (And I have no contact with either of these groups.) rick Bye, Alexander. -- http://www.Leidinger.net alexan...@leidinger.net: PGP 0x8F31830F9F2772BF http://www.FreeBSD.orgnetch...@freebsd.org : PGP 0x8F31830F9F2772BF
Re: [RFC] Making mount_nfs to attempt NFSv4 before NFSv3 and NFSv2?
Quoting Rick Macklem (from Tue, 4 Jan 2022 03:18:36 +): Konstantin Belousov wrote: [good stuff snipped] The v4 NFS is very different from v3, it is not an upgrade, it is rather a different network filesystem with some (significant) similarities to v3. That said, it should be fine changing the defaults, but you need to ensure that reasonable scenarios, like the changed FreeBSD client mounting from v3-only server, still work correctly. The change should be made in a way that only affects client that connects to the server that has both v4 and v3. A particular test case that needs to be done is the diskless NFS root fs. This case must use NFSv3 and if it is not the default, it might break? I am not really set up to test this at this time. (There are assorted reasons that NFSv4 does not, or at least might not, work for a diskless root fs, but that is a separate topic.) Other than testing diskless NFS root file systems, I do not have a strong opinion w.r.t. whether the default should change. If the default stays as NFSv3, a fallback to NFSv4 could be done, which would handle the NFSv4 only server case. (No one uses NFSv2 any more, so the fallback to NFSv2 is almost irrelevant, imho.) As you particiate in interoperability tests, would it make sense to check how those other implementations handle this case? I naively assume you have some contacts or a mailinglist you could use for that. Bye, Alexander. -- http://www.Leidinger.net alexan...@leidinger.net: PGP 0x8F31830F9F2772BF http://www.FreeBSD.orgnetch...@freebsd.org : PGP 0x8F31830F9F2772BF
Re: [RFC] Making mount_nfs to attempt NFSv4 before NFSv3 and NFSv2?
Konstantin Belousov wrote: [good stuff snipped] > The v4 NFS is very different from v3, it is not an upgrade, it is rather > a different network filesystem with some (significant) similarities to v3. > > That said, it should be fine changing the defaults, but you need to ensure > that reasonable scenarios, like the changed FreeBSD client mounting > from v3-only server, still work correctly. The change should be made in a > way that only affects client that connects to the server that has both > v4 and v3. A particular test case that needs to be done is the diskless NFS root fs. This case must use NFSv3 and if it is not the default, it might break? I am not really set up to test this at this time. (There are assorted reasons that NFSv4 does not, or at least might not, work for a diskless root fs, but that is a separate topic.) Other than testing diskless NFS root file systems, I do not have a strong opinion w.r.t. whether the default should change. If the default stays as NFSv3, a fallback to NFSv4 could be done, which would handle the NFSv4 only server case. (No one uses NFSv2 any more, so the fallback to NFSv2 is almost irrelevant, imho.) rick
Re: [RFC] Making mount_nfs to attempt NFSv4 before NFSv3 and NFSv2?
On Tue, Jan 04, 2022 at 09:07:47AM +0900, Tomoaki AOKI wrote:
> I myself never used NFS, but I don't think it a POLA violation,
> because...
> *Keeping latest-stable (formerly, v3?) to oldest (v2) order.
>
> *Usually, once new version is considered stable, security fixes
>are first done on the latest, then backported to older revs,
>causing delay. It can cause fatal security incident for servers.
>So always as newer as possible rev should be always preferred
>unless no specific rev is specified.
>
> But development versions would better not automatically selected.
> If v4 is already considered as production quality on FreeBSD,
> it would be best preferred first on automatic selection.
>
> On Mon, 3 Jan 2022 10:51:31 -0800
> Xin Li via freebsd-current wrote:
>
> > Hi,
> >
> > Currently, mount_nfs will attempt to use NFSv3 and fallback to NFSv2.
> > The manual page says:
> >
> > nfsv2 Use the NFS Version 2 protocol (the default is to try
> > version 3 first then version 2). Note that NFS version 2
> > has a file size limit of 2 gigabytes.
> >
> > And the code agrees, too:
> >
> >
> > if (trymntmode == V4) {
> > nfsvers = 4;
> > mntvers = 3; /* Workaround for GCC. */
> > } else if (trymntmode == V2) {
> > nfsvers = 2;
> > mntvers = 1;
> > } else {
> > nfsvers = 3;
> > mntvers = 3;
> > }
> >
> >
> > When trymntmode == ANY, which is the default, mount_nfs would attempt
> > NFSv3, and if rpcb_getaddr() returned RPC_PROGVERSMISMATCH, it would try
> > again with trymntmode = V2.
> >
> > Nowadays, it seems that NFSv4 is becoming more and more popular. If a
> > server is providing only NFSv4 service, when mounting without -o nfsv4,
> > the user would receive message like:
> >
> > RPCPROG_MNT: RPC:Timed out
> >
> > A friend of mine who is using TrueNAS core hit this yesterday and his
> > Linux client worked just fine. It took me some time to figure out that
> > the root cause. It seems that modern Linux distributions have been
> > using NFSv4 by default for some time.
> >
> > So I think it makes sense to teach mount_nfs to attempt NFSv4, then
> > NFSv3 and NFSv2. However, this might be a POLA violation and we would
> > like to know if there is any objections.
> >
> > (I've attached a patch but I haven't actually tested it yet).
The v4 NFS is very different from v3, it is not an upgrade, it is rather
a different network filesystem with some (significant) similarities to v3.
That said, it should be fine changing the defaults, but you need to ensure
that reasonable scenarios, like the changed FreeBSD client mounting
from v3-only server, still work correctly. The change should be made in a
way that only affects client that connects to the server that has both
v4 and v3.
Re: [RFC] Making mount_nfs to attempt NFSv4 before NFSv3 and NFSv2?
On Tue, Jan 04, 2022 at 12:15:12AM +, Colin Percival wrote: > On 1/3/22 10:51, Xin Li wrote: > > [...] > > So I think it makes sense to teach mount_nfs to attempt NFSv4, then > > NFSv3 and NFSv2. However, this might be a POLA violation and we would > > like to know if there is any objections. > > This seems like a sensible change of defaults to make in 14-CURRENT; please > add an entry to RELNOTES so that users will be alerted to the change. > > I don't think this should be MFCed. > I am torn on the topic, and would like to hear feedback from others that use NFS (I personally do not, so this change does not affect me). I will agree with whatever is the outcome of the majority. Glen signature.asc Description: PGP signature
Re: [RFC] Making mount_nfs to attempt NFSv4 before NFSv3 and NFSv2?
I myself never used NFS, but I don't think it a POLA violation,
because...
*Keeping latest-stable (formerly, v3?) to oldest (v2) order.
*Usually, once new version is considered stable, security fixes
are first done on the latest, then backported to older revs,
causing delay. It can cause fatal security incident for servers.
So always as newer as possible rev should be always preferred
unless no specific rev is specified.
But development versions would better not automatically selected.
If v4 is already considered as production quality on FreeBSD,
it would be best preferred first on automatic selection.
On Mon, 3 Jan 2022 10:51:31 -0800
Xin Li via freebsd-current wrote:
> Hi,
>
> Currently, mount_nfs will attempt to use NFSv3 and fallback to NFSv2.
> The manual page says:
>
> nfsv2 Use the NFS Version 2 protocol (the default is to try
> version 3 first then version 2). Note that NFS version 2
> has a file size limit of 2 gigabytes.
>
> And the code agrees, too:
>
>
> if (trymntmode == V4) {
> nfsvers = 4;
> mntvers = 3; /* Workaround for GCC. */
> } else if (trymntmode == V2) {
> nfsvers = 2;
> mntvers = 1;
> } else {
> nfsvers = 3;
> mntvers = 3;
> }
>
>
> When trymntmode == ANY, which is the default, mount_nfs would attempt
> NFSv3, and if rpcb_getaddr() returned RPC_PROGVERSMISMATCH, it would try
> again with trymntmode = V2.
>
> Nowadays, it seems that NFSv4 is becoming more and more popular. If a
> server is providing only NFSv4 service, when mounting without -o nfsv4,
> the user would receive message like:
>
> RPCPROG_MNT: RPC:Timed out
>
> A friend of mine who is using TrueNAS core hit this yesterday and his
> Linux client worked just fine. It took me some time to figure out that
> the root cause. It seems that modern Linux distributions have been
> using NFSv4 by default for some time.
>
> So I think it makes sense to teach mount_nfs to attempt NFSv4, then
> NFSv3 and NFSv2. However, this might be a POLA violation and we would
> like to know if there is any objections.
>
> (I've attached a patch but I haven't actually tested it yet).
>
> Cheers,
--
Tomoaki AOKI
[RFC] Making mount_nfs to attempt NFSv4 before NFSv3 and NFSv2?
Hi,
Currently, mount_nfs will attempt to use NFSv3 and fallback to NFSv2.
The manual page says:
nfsv2 Use the NFS Version 2 protocol (the default is to try
version 3 first then version 2). Note that NFS version 2
has a file size limit of 2 gigabytes.
And the code agrees, too:
if (trymntmode == V4) {
nfsvers = 4;
mntvers = 3; /* Workaround for GCC. */
} else if (trymntmode == V2) {
nfsvers = 2;
mntvers = 1;
} else {
nfsvers = 3;
mntvers = 3;
}
When trymntmode == ANY, which is the default, mount_nfs would attempt
NFSv3, and if rpcb_getaddr() returned RPC_PROGVERSMISMATCH, it would try
again with trymntmode = V2.
Nowadays, it seems that NFSv4 is becoming more and more popular. If a
server is providing only NFSv4 service, when mounting without -o nfsv4,
the user would receive message like:
RPCPROG_MNT: RPC:Timed out
A friend of mine who is using TrueNAS core hit this yesterday and his
Linux client worked just fine. It took me some time to figure out that
the root cause. It seems that modern Linux distributions have been
using NFSv4 by default for some time.
So I think it makes sense to teach mount_nfs to attempt NFSv4, then
NFSv3 and NFSv2. However, this might be a POLA violation and we would
like to know if there is any objections.
(I've attached a patch but I haven't actually tested it yet).
Cheers,From eb6e60233d840d072d0280325ca2cb37455dc2f1 Mon Sep 17 00:00:00 2001
From: Xin LI
Date: Mon, 3 Jan 2022 10:48:17 -0800
Subject: [PATCH] mount_nfs: Attempt NFSv4 before NFSv3 and NFSv2.
---
sbin/mount_nfs/mount_nfs.8 | 6 +++---
sbin/mount_nfs/mount_nfs.c | 29 -
2 files changed, 23 insertions(+), 12 deletions(-)
diff --git a/sbin/mount_nfs/mount_nfs.8 b/sbin/mount_nfs/mount_nfs.8
index 648cb2128e90..741b5c24a080 100644
--- a/sbin/mount_nfs/mount_nfs.8
+++ b/sbin/mount_nfs/mount_nfs.8
@@ -28,7 +28,7 @@
.\" @(#)mount_nfs.8 8.3 (Berkeley) 3/29/95
.\" $FreeBSD$
.\"
-.Dd July 10, 2021
+.Dd January 10, 2022
.Dt MOUNT_NFS 8
.Os
.Sh NAME
@@ -216,8 +216,8 @@ This option requires the
.Cm nfsv4
option.
.It Cm nfsv2
-Use the NFS Version 2 protocol (the default is to try version 3 first
-then version 2).
+Use the NFS Version 2 protocol (the default is to try version 4 first,
+then version 3, then version 2).
Note that NFS version 2 has a file size limit of 2 gigabytes.
.It Cm nfsv3
Use the NFS Version 3 protocol.
diff --git a/sbin/mount_nfs/mount_nfs.c b/sbin/mount_nfs/mount_nfs.c
index e1eaf206e982..e6d7e0afbfb7 100644
--- a/sbin/mount_nfs/mount_nfs.c
+++ b/sbin/mount_nfs/mount_nfs.c
@@ -125,6 +125,7 @@ static enum mountmode {
ANY,
V2,
V3,
+ V3orV2,
V4
} mountmode = ANY;
@@ -777,15 +778,21 @@ nfs_tryproto(struct addrinfo *ai, char *hostp, char *spec, char **errstr,
}
tryagain:
- if (trymntmode == V4) {
+ switch (trymntmode) {
+ case V4:
+ case ANY:
nfsvers = 4;
mntvers = 3; /* Workaround for GCC. */
- } else if (trymntmode == V2) {
- nfsvers = 2;
- mntvers = 1;
- } else {
+ break;
+ case V3orV2:
+ case V3:
nfsvers = 3;
mntvers = 3;
+ break;
+ case V2:
+ nfsvers = 2;
+ mntvers = 1;
+ break;
}
if (portspec != NULL) {
@@ -799,10 +806,14 @@ nfs_tryproto(struct addrinfo *ai, char *hostp, char *spec, char **errstr,
if (!rpcb_getaddr(NFS_PROGRAM, nfsvers, nconf, _nb,
hostp)) {
- if (rpc_createerr.cf_stat == RPC_PROGVERSMISMATCH &&
- trymntmode == ANY) {
-trymntmode = V2;
-goto tryagain;
+ if (rpc_createerr.cf_stat == RPC_PROGVERSMISMATCH) {
+if (trymntmode == ANY) {
+ trymntmode = V3orV2;
+ goto tryagain;
+} else if (trymntmode == V3orV2) {
+ trymntmode = V2;
+ goto tryagain;
+}
}
snprintf(errbuf, sizeof errbuf, "[%s] %s:%s: %s",
netid, hostp, spec,
--
2.34.1
