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@xxxxxxxxxx>
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
