On 12/8/24 2:41 AM, Cedric Blancher wrote:
On Fri, 6 Dec 2024 at 16:54, Chuck Lever <chuck.lever@xxxxxxxxxx> 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.
I think the minimum support Roland added (or what is left of it)
should remain. It covers read-only ("ro=1") and read-write ("rw=1")
attributes, which are clearly a property of the exported path.
Correct, the server mandates the security policy. However, a client
can mount an RO export any way it likes. It's not an error for a client
to mount an RO export with RW. Writes will fail. Mounting will not.
exportfs -U generates nfs URLs with "?ro=1" for read-only exports, and> mount.nfs4 should treat such urls as the standard mandates, and not
either drop an attribute (which is a violation of rfc 1738) or reject
a mount request because support for "ro" parameter was dropped in this
patch.
The only standards language I can find regarding query components is
the section of RFC 7532 I quoted here yesterday:
An NFS URI MUST contain both an authority and a path component. It
MUST NOT contain a query component or a fragment component. Use of
the familiar "nfs" scheme name is retained.
Therefore all of the parameter mechanism needs to be postponed until
these details can be sorted out by standards action. Otherwise, we
risk implementing something non-standard, or worse, incompatible with
the standard, that will have to be maintained for a long time.
This is not a NAK; rather it's a "that's not ready yet" objection.
It's basically a way of getting the working parts merged sooner rather
than having them wait until every last detail is worked out.
Note that I will have the same objection to "exportfs -U" whenever
that materializes -- it should not emit URL query components that
haven't yet been standardized.
You do want URL copy-and-paste between NFS implementations to work
nicely, yes?
- 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?
NFSv3 is obsolete. Redhat support keeps telling us that for almost ten
years now.
That is wishful thinking on Red Hat's part. Hammerspace is making
a business out of supporting NFSv3 data servers today, just as one
example.
Linux upstream still considers NFSv3 fully supported.
--
Chuck Lever
