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. 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? > > > > 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. Those are usually inside [] I think. > > 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. Are they? Where? That certainly might be a good justification. 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. Thanks, NeilBrown
