From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from gate001.proxmox.com (gate001.proxmox.com [IPv6:2a0f:8001:1:32::40]) by lore.proxmox.com (Postfix) with ESMTPS id 90FE61FF150 for ; Mon, 06 Jul 2026 16:20:09 +0200 (CEST) Received: from gate001.proxmox.com (localhost.localdomain [127.0.0.1]) by gate001.proxmox.com (Proxmox) with ESMTP id 643182145F; Mon, 06 Jul 2026 16:20:08 +0200 (CEST) From: Maximiliano Sandoval To: Fiona Ebner Subject: Re: [PATCH storage v3 2/2] nfs: use rpcinfo as a showmounts fallback for nfs3 In-Reply-To: <037f3b57-2137-4738-8dbc-7571c6a0c144@proxmox.com> (Fiona Ebner's message of "Mon, 6 Jul 2026 15:01:43 +0200") References: <20260325124646.298999-1-m.sandoval@proxmox.com> <20260325124646.298999-3-m.sandoval@proxmox.com> <037f3b57-2137-4738-8dbc-7571c6a0c144@proxmox.com> User-Agent: mu4e 1.12.9; emacs 30.1 Date: Mon, 06 Jul 2026 16:19:34 +0200 Message-ID: MIME-Version: 1.0 Content-Type: text/plain X-Bm-Milter-Handled: 55990f41-d878-4baa-be0a-ee34c49e34d2 X-Bm-Transport-Timestamp: 1783347568777 X-SPAM-LEVEL: Spam detection results: 0 DMARC_MISSING 0.1 Missing DMARC policy KAM_DMARC_STATUS 0.01 Test Rule for DKIM or SPF Failure with Strict Alignment (newer systems) SPF_HELO_NONE 0.001 SPF: HELO does not publish an SPF Record SPF_PASS -0.001 SPF: sender matches SPF record Message-ID-Hash: MGJXVCZHI3RFCPLKOIK6N2P34LTJXAAH X-Message-ID-Hash: MGJXVCZHI3RFCPLKOIK6N2P34LTJXAAH X-MailFrom: m.sandoval@proxmox.com X-Mailman-Rule-Misses: dmarc-mitigation; no-senders; approved; loop; banned-address; emergency; member-moderation; nonmember-moderation; administrivia; implicit-dest; max-recipients; max-size; news-moderation; no-subject; digests; suspicious-header CC: pve-devel@lists.proxmox.com X-Mailman-Version: 3.3.10 Precedence: list List-Id: Proxmox VE development discussion List-Help: List-Owner: List-Post: List-Subscribe: List-Unsubscribe: Fiona Ebner writes: > Am 25.03.26 um 1:46 PM schrieb Maximiliano Sandoval: >> The check_connection call must succeed in order for the NFS storage to >> be activated. In a setup in which the NFS server does not list exports >> and which only supports NFSv3 this would result in the storage not being >> usable (not without manually mounting the NFS share and using a >> Directory storage instead). We add a fallback check with rpcinfo for >> this case. >> >> The rpcinfo check was replaced with showmounts in f8b0d82fe. At the time > > Typo: s/showmounts/showmount/ > >> the rationale was that rpcinfo did not have support for ipv6 >> connections, which does not hold anymore. >> >> In order to not break compatibility with setups that already activate >> correctly, we add a rpcinfo check as a fallback for NFSv3-only setups >> only after the showmounts command fails. > > Typo: s/showmounts/showmount/ > >> >> Potential pitfalls: >> - Some NFSv3 servers might only support UDP [RFC 1813] > > Also relevant for switching to only using rpcinfo. Could you extend the > TODO PVE 10 comment with this pitfall? > >> - The two timeouts add up to 20 seconds > > Is the timeout for the first command hit in case the server does not > list exports? Or does the command fail differently? If it's the former > case, it would be nice to avoid that, since a 10 second delay on every > activate_storage() is still bad from a user perspective. > > Were there good reasons for the customer's server not to list the > exports? If not, we could also just document the requirement for NFSv3? > It was more of a: "there is potentially a worst-cast scenario of a 20 second timeout" and I do not know if it is safe to run a potentially 20 second-long operation here. I do not remember finding such a case, but it might be out there. I will rephrase this. > [..] -- Maximiliano