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

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

On 12/7/24 3:53 PM, NeilBrown wrote:
> On Sat, 07 Dec 2024, Chuck Lever wrote:
>> Hi Roland, thanks for posting.
>>
>> Here are some initial review comments to get the ball rolling.
>>
>>
>> On 12/6/24 5:54 AM, Roland Mainz wrote:
>>> Hi!
>>>
>>> ----
>>>
>>> Below (and also available at https://nrubsig.kpaste.net/b37) is a
>>> patch which adds support for nfs://-URLs in mount.nfs4, as alternative
>>> to the traditional hostname:/path+-o port=<tcp-port> notation.
>>>
>>> * Main advantages are:
>>> - Single-line notation with the familiar URL syntax, which includes
>>> hostname, path *AND* TCP port number (last one is a common generator
>>> of *PAIN* with ISPs) in ONE string
>>> - Support for non-ASCII mount points, e.g. paths with CJKV (Chinese,
>>
>> s/mount points/export paths
>>
>> (When/if you need to repost, you should move this introductory text into
>> a cover letter.)
>>
>>
>>> Japanese, ...) characters, which is typically a big problem if you try
>>> to transfer such mount point information across email/chat/clipboard
>>> etc., which tends to mangle such characters to death (e.g.
>>> transliteration, adding of ZWSP or just '?').
>>> - URL parameters are supported, providing support for future extensions
>>
>> IMO, any support for URL parameters should be dropped from this
>> patch and then added later when we know what the parameters look
>> like. Generally, we avoid adding extra code until we have actual
>> use cases. Keeps things simple and reduces technical debt and dead
>> code.
>>
>>
>>> * Notes:
>>> - Similar support for nfs://-URLs exists in other NFSv4.*
>>> implementations, including Illumos, Windows ms-nfs41-client,
>>> sahlberg/libnfs, ...
>>
>> The key here is that this proposal is implementing a /standard/
>> (RFC 2224).
> 
> Actually it isn't.  You have already discussed the pub/root filehandle
> difference.

RFC 2224 specifies both. Pub vs. root filehandles are discussed
there, along with how standard NFS URLs describe either situation.


> The RFC doesn't know about v4.  The RFC explicitly isn't a
> standard.

RFC 7532 contains the NFSv4 bits. RFC 2224 is not a Normative
standard, like all early NFS-related RFCs, but it is a
specification that other implementations cleave to. RFC 7532
/is/ a Normative standard.


> So I wonder if this is the right approach to solve the need.
> 
> What is the needed?
> Part of it seems to be non-ascii host names.  Shouldn't we fix that for
> the existing syntax?  What are the barriers?

Both non-ASCII hostnames (iDNA) and export paths can contain
components with non-ASCII characters.

The issue is how to specify certain code points when the client's
locale might not support them. Using a URL seems to be the mechanism
chosen by several other NFS implementations to deal with this problem.


> Part seems to be the inclusion of the port number.  Is a "URL" really
> the best way to solve that need?
> Mount.nfs currently expects ":/" to separate host name from path.
> I think host:port:/path would be unambiguous providing "port" did not
> start "/".

There's also IPv6 presentation addresses, which contain ":" already.

However host:port:/path is not something that other NFS implementations
(eg that might share an automounter map) would understand. There is a
significantly higher likelihood that those implementations would be
able to interpret an NFS URI correctly.

I'm not especially convinced by the arguments about port numbers, but
I don't happen to use alternate ports daily.


> Do we really need the % encoding that the URL syntax gives us?  If so -
> why?

See above. Character set translation issues.

And note that NFS URIs are coming soon to other parts of the Linux NFS
administrative interface. No reason that mount.nfs should not also
support them properly.


-- 
Chuck Lever