From nobody Tue Jan 4 03:04:46 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 CEC101931AE3 for ; Tue, 4 Jan 2022 03:05:14 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from kib.kiev.ua (kib.kiev.ua [IPv6:2001:470:d5e7:1::1]) (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 4JSctL43Gbz3jjZ; Tue, 4 Jan 2022 03:05:14 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from tom.home (kib@localhost [127.0.0.1]) by kib.kiev.ua (8.16.1/8.16.1) with ESMTPS id 20434liE005942 (version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384 bits=256 verify=NO); Tue, 4 Jan 2022 05:04:50 +0200 (EET) (envelope-from kostikbel@gmail.com) DKIM-Filter: OpenDKIM Filter v2.10.3 kib.kiev.ua 20434liE005942 Received: (from kostik@localhost) by tom.home (8.16.1/8.16.1/Submit) id 20434kGW005939; Tue, 4 Jan 2022 05:04:46 +0200 (EET) (envelope-from kostikbel@gmail.com) X-Authentication-Warning: tom.home: kostik set sender to kostikbel@gmail.com using -f Date: Tue, 4 Jan 2022 05:04:46 +0200 From: Konstantin Belousov To: Tomoaki AOKI Cc: freebsd-current@freebsd.org, 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: References: <20220104090747.7767144800c564ca2cff43d5@dec.sakura.ne.jp> 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-Disposition: inline In-Reply-To: <20220104090747.7767144800c564ca2cff43d5@dec.sakura.ne.jp> X-Spam-Status: No, score=-1.0 required=5.0 tests=ALL_TRUSTED,BAYES_00, DKIM_ADSP_CUSTOM_MED,FORGED_GMAIL_RCVD,FREEMAIL_FROM, NML_ADSP_CUSTOM_MED autolearn=no autolearn_force=no version=3.4.5 X-Spam-Checker-Version: SpamAssassin 3.4.5 (2021-03-20) on tom.home X-Rspamd-Queue-Id: 4JSctL43Gbz3jjZ X-Spamd-Bar: ---- Authentication-Results: mx1.freebsd.org; none X-Spamd-Result: default: False [-4.00 / 15.00]; REPLY(-4.00)[] X-Spam: Yes X-ThisMailContainsUnwantedMimeParts: N 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.