Re: [PATCH storage v3 2/2] nfs: use rpcinfo as a showmounts fallback for nfs3

[Maximiliano Sandoval <m.sandoval@proxmox.com>]

Fiona Ebner <f.ebner@proxmox.com> 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