From nobody Tue Jan 4 00:07:47 2022 X-Original-To: freebsd-current@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 13C43191FC5B for ; Tue, 4 Jan 2022 00:08:10 +0000 (UTC) (envelope-from junchoon@dec.sakura.ne.jp) Received: from www121.sakura.ne.jp (www121.sakura.ne.jp [153.125.133.21]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 4JSXy14lNKz4qQX; Tue, 4 Jan 2022 00:08:08 +0000 (UTC) (envelope-from junchoon@dec.sakura.ne.jp) Received: from kalamity.joker.local (123-48-130-181.area1b.commufa.jp [123.48.130.181]) (authenticated bits=0) by www121.sakura.ne.jp (8.16.1/8.16.1/[SAKURA-WEB]/20201212) with ESMTPA id 20407lOq088830; Tue, 4 Jan 2022 09:07:47 +0900 (JST) (envelope-from junchoon@dec.sakura.ne.jp) Date: Tue, 4 Jan 2022 09:07:47 +0900 From: Tomoaki AOKI To: freebsd-current@freebsd.org Cc: d@delphij.net, rmacklem@freebsd.org, "re@FreeBSD.org Engineering Team" Subject: Re: [RFC] Making mount_nfs to attempt NFSv4 before NFSv3 and NFSv2? Message-Id: <20220104090747.7767144800c564ca2cff43d5@dec.sakura.ne.jp> In-Reply-To: References: Organization: Junchoon corps X-Mailer: Sylpheed 3.7.0 (GTK+ 2.24.33; amd64-portbld-freebsd13.0) List-Id: Discussions about the use of FreeBSD-current List-Archive: https://lists.freebsd.org/archives/freebsd-current List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-current@freebsd.org Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-Rspamd-Queue-Id: 4JSXy14lNKz4qQX X-Spamd-Bar: ---- Authentication-Results: mx1.freebsd.org; none X-Spamd-Result: default: False [-4.00 / 15.00]; REPLY(-4.00)[] X-ThisMailContainsUnwantedMimeParts: N 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