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. -- Jeff Layton <jlayton@xxxxxxxxxx>
