On Sun, 2024-05-26 at 16:12 +0200, Martin Wege wrote: > On Sun, May 26, 2024 at 1:28 PM Jeff Layton <jlayton@xxxxxxxxxx> wrote: > > > > On Fri, 2024-05-24 at 19:11 +0200, Dan Shelton wrote: > > > On Wed, 15 May 2024 at 23:46, Steve Dickson <steved@xxxxxxxxxx> wrote: > > > > > > > > Hey! > > > > > > > > On 5/14/24 5:57 PM, Dan Shelton wrote: > > > > > Hello! > > > > > > > > > > Solaris, Windows and libnfs NFSv4 clients support RFC2224 URLs, which > > > > > provide platform-independent paths where resources can be mounted > > > > > from, i.e. nfs://myhost//dir1/dir2 > > > > > > > > > > Could Linux /sbin/mount.nfs4 support this too, please? > > > > Why? What does it bring to the table that the Linux client > > > > does already do via v4... with the except, of course, public > > > > filehandles, which is something I'm pretty sure the Linux > > > > client will not support. > > > > > > This is NOT for Linux only. Every OS has its own system to describe > > > shares, and not all are compatible. URLs are portable. > > > > > > > > > > > So again why? WebNFS died with Sun... Plus RFC2224 talks > > > > about v2 and v3... How does it fit in a V4 world. > > > > > > This is NOT about WebNFS or SUN, this is to make the job of admins easier. > > > > > > > I think Steve is just trying to get at the use-case for this. Who is > > using nfs:// URLs in their environment, and why? IOW, how will adding > > this make things better? > > > > Then there are the more practical questions: > > > > - will this require kernel support? If I mount using a nfs:// URL, > > should I expect to see that in /proc/self/mounts, instead of a > > host:/export ? > > > > - do you need support for public filehandles? Those were largely > > ignored by most NFS implementors, including Linux. That opens an > > entirely separate can of worms. > > > > I'm happy to consider patches that add support for this (including > > documentation), but I'd need to understand why this is a material > > improvement over the traditional ":/" syntax. > > > > No, traditional syntax is :\, traditional syntax is UNC form, > traditional syntax is GUI with hostname and path fields. No, > traditional syntax are options -H hostname, -P path. > > Seems there is no tradition, just every software on Linux, PC/Windows, > MAC has its own syntax. Therefore I would agree that a platform > independent standard would be good > I meant traditional NFS mount device syntax, which has been "hostname:/path" since the v2 days (at least). In any case, there is little point in arguing about this without some justification and code to back it up. AFAICS, the only benefit to this is that you wouldn't need to separately specify that this string meant an NFS mount, since you can infer that from the URL prefix. Most of the tools we work with that handle mounts (e.g. fstab, systemd mount unit syntax, k8s, etc...) require you to specify the mount type separately anyway. So, I'll ask again...where do you plan to use this feature? What downstream changes to tooling can we expect to see if we were to have mount.nfs understand this syntax? Will you also be patching /bin/mount to recognize NFS URLs and pass them along to the right mount helper? -- Jeff Layton <jlayton@xxxxxxxxxx>
