On 12/7/24 10:29 PM, NeilBrown wrote:
On Sun, 08 Dec 2024, Chuck Lever wrote:
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.
The usage in RFC 7532 is certainly more convincing than 2224.
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.
But they cannot contain non-Unicode characters, so UTF-8 should be
sufficient.
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.
If locale-mismatch is a problem, it isn't clear to me that "mount.nfs"
is the place to solve it.
The problem is presented as:
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 '?').
So it sounds like the problem is copy/paste. I doubt that NFS addresses
are the only things that can get corrupted.
Maybe a more generic tool would be appropriate.
I agree. The cited copy/paste use case is pretty weak.
How are people going to create the nfs: urls so they can paste them into
the chat? In there a reverse tool for getting them out?
Or we just just adding a hack to avoid "*PAIN* with ISPs" rather then
getting the ISPs to fix their breakage?
I tend to think our administrative interfaces could be made easier
to use, over all.
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.
Are they? Where? That certainly might be a good justification.
The nfsref command will need to take NFS URLs in order to specify
alternate port information in referrals. Tom Haynes is working on
the standards part of this, I'm told.
nfs: urls were introduced precisely for WebNFS (as I understand it). So
when the post said "This is not about WebNFS" I had to wonder if they
were really the right tool for a very different task. Maybe they are,
but I think comprehensive justification is needed.
I agree that the justification needs to be much stronger. The
i18n stuff is complicated and needs better explanation for us
mere mortals to understand.
That said, support for NFS URLs is missing in Linux anyway, IMO.
I don't think it hurts us to add it.
--
Chuck Lever
