Re: [patch] mount.nfs: Add support for nfs://-URLs ...

[Chuck Lever <chuck.lever@oracle.com>]

On 12/7/24 10:20 AM, Chuck Lever wrote:
> On 12/6/24 6:33 PM, Roland Mainz wrote:
>> On Fri, Dec 6, 2024 at 4:54 PM Chuck Lever <chuck.lever@oracle.com> 
>> wrote:

>>>> - This feature will not be provided for NFSv3
>>>
>>> Why shouldn't mount.nfs also support using an NFS URL to mount an
>>> NFSv3-only server? Isn't this simply a matter of letting mount.nfs
>>> negotiate down to NFSv3 if needed?
>>
>> Two issues:
>> 1. I consider NFSv2/NFSv3/NFSv4.0 as obsolete
> 
> NFSv2 is obsolete, yes.
> 
> The NFSv3 standard is not being updated, but NFSv3 is broadly
> deployed and implementations are actively maintained. It's not
> obsolete.
> 
> NFSv4.0 is on its way out, but is not obsolete yet. I don't
> think it would be challenging to include support here.

(Indeed, I presumed that /excluding/ minor version 0 would require
some extra work. But maybe that's not true).


>> 2. It would be much more complex because we need to think about how to
>> encode rpcbind&transport parameters, e.g. in cases of issues like
>> custom rpcbind+mountd ports, and/or UDP.
> 
> This is much more than is needed, IMO. NFSv3 can stick with the
> standard rpcbind port, an rpcbind query for MNT. My reading of
> the RFCs suggests that for NFSv3, the transport protocol is
> selected based on what both sides support.
> 
> I think we want to avoid trying to build every bell and whistle
> into the mount.nfs NFS URL implementation. Just cover the basics,
> at least in the initial implementation.
> 
> 
>> That will quickly escalate
>> and require lots of debates. We had that debate already in ~~2006 when
>> I was at SUN Microsystems, and there was never a consensus on how to
>> do nfs://-URLs for NFSv3 outside WebNFS.
>>
>> I think it can be done, IMHO but this is way outside of the scope of
>> this patch, which is mainly intended to fix some *URGENT* issues like
>> paths with non-ASCII characters for the CJKV people and implement
>> "hostport" notation (e.g. keep hostname+port in one string together).

I don't understand your comment about scope.

The scope of this patch, I thought, was to implement RFC 2224-compliant
NFS URLs for the mount.nfs command line. NFSv3 is specified right there
in that RFC. It seems to me that NFSv3 is indeed within scope, and
NFSv4 is in fact not (if you want to be pedantic about it).

And I don't see why handling NFSv3 should be difficult: The URL parser
should simply translate the URL into equivalent command line options
and pass those to the stropt code. That will handle NFS version and
transport negotiation automatically, yes?

Administrators will expect to be able to control the version negotiation
behavior via settings in /etc/nfs.conf. If NFS URLs bypass mount.nfs's
version negotiation (and therefore do not comply with the settings in
/etc/nfs.conf), I think that is not correct and will be disappointing
to administrators.


-- 
Chuck Lever