From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from gate001.proxmox.com (gate001.proxmox.com [45.144.208.40]) by lore.proxmox.com (Postfix) with ESMTPS id 89C801FF146 for ; Tue, 07 Jul 2026 10:06:48 +0200 (CEST) Received: from gate001.proxmox.com (localhost.localdomain [127.0.0.1]) by gate001.proxmox.com (Proxmox) with ESMTP id 5C6E821443; Tue, 07 Jul 2026 10:06:47 +0200 (CEST) Message-ID: Date: Tue, 7 Jul 2026 10:06:43 +0200 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH storage v4 2/2] nfs: use rpcinfo as a showmount fallback for nfs3 To: Maximiliano Sandoval References: <20260706143638.509139-1-m.sandoval@proxmox.com> <20260706143638.509139-3-m.sandoval@proxmox.com> Content-Language: en-US From: Fiona Ebner In-Reply-To: Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-Bm-Milter-Handled: 55990f41-d878-4baa-be0a-ee34c49e34d2 X-Bm-Transport-Timestamp: 1783411596545 X-SPAM-LEVEL: Spam detection results: 0 AWL 0.037 Adjusted score from AWL reputation of From: address 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: 6WO6FSIMVM5NMIQCXKKEQ6JA7TJ5WT2H X-Message-ID-Hash: 6WO6FSIMVM5NMIQCXKKEQ6JA7TJ5WT2H X-MailFrom: f.ebner@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: Am 07.07.26 um 9:37 AM schrieb Maximiliano Sandoval: > Fiona Ebner writes: > >> Am 06.07.26 um 4:37 PM schrieb Maximiliano Sandoval: >>> diff --git a/src/PVE/Storage/NFSPlugin.pm b/src/PVE/Storage/NFSPlugin.pm >>> index 56dbd9ec..4fe7695a 100644 >>> --- a/src/PVE/Storage/NFSPlugin.pm >>> +++ b/src/PVE/Storage/NFSPlugin.pm >>> @@ -198,6 +198,11 @@ sub check_connection { >>> # no exports are listed >>> $cmd = $nfs_get_rpcinfo_command->($server, '4'); >>> } else { >>> + # FIXME: PVE 10: Consider switching to rpcinfo altogether. >>> + # There are some potential pitfalls: >>> + # - Some NFSv3 servers might only support UDP (cf. RFC 1813, Section 2.3) >>> + # - The two timeouts add up to a potential worst-case scenario of 20 seconds >> >> This is not a pitfall for to the switch to rpcinfo, but related to your >> current implementation with showmount+rpcinfo. It's rather easy to spot, >> so not sure it needs a comment in the code. I'd rather have it in the >> commit message. > > Running into timeouts is a very common issue in Enterprise support, I do > have a strong preference for keeping it as explicit as possible. But please don't mention it in the pitfalls for the switch to rpcbind, but clearly state that it's about the current implementation. Otherwise, that is just confusing.