Received-SPF: pass (google.com: domain of linux-nfs+bounces-3397-linux.lists.archive=gmail.com@vger.kernel.org designates 2604:1380:45d1:ec00::1 as permitted sender) client-ip=2604:1380:45d1:ec00::1;
Precedence: bulk
MIME-Version: 1.0
References: <CAAvCNcCTWbU-ejURuUC0_xhcoU3GF+2jX28rV4+2cKgfO5Lqxg@mail.gmail.com>
 <619bbf23-dbfe-4c26-adb9-1cc89f3f22a2@redhat.com> <CAAvCNcCGhZ917yerEOMcEEj7+_Yz5by8en2F4Yr5zLk0iQEGjg@mail.gmail.com>
 <ee3805865e12f8ed2f82f7e99e33598f0bcc6667.camel@kernel.org> <CANH4o6MHtYVFaciH=Xh-Ph3x_AXuiYNVmhU2akzYwbQ_MmFPcA@mail.gmail.com>
In-Reply-To: <CANH4o6MHtYVFaciH=Xh-Ph3x_AXuiYNVmhU2akzYwbQ_MmFPcA@mail.gmail.com>
From: Cedric Blancher <cedric.blancher@gmail.com>
Date: Mon, 27 May 2024 07:16:00 +0200
Message-ID: <CALXu0UfDKQsbL2aTZwaBv3uVT3BAys3cWxMObZRt_xi_M9VM9Q@mail.gmail.com>
Subject: Re: RFC2224 support in Linux /sbin/mount.nfs4?
To: Linux NFS Mailing List <linux-nfs@vger.kernel.org>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

On Sun, 26 May 2024 at 16:13, Martin Wege <martin.l.wege@gmail.com> wrote:
>
> On Sun, May 26, 2024 at 1:28=E2=80=AFPM Jeff Layton <jlayton@kernel.org> =
wrote:
> >
> > On Fri, 2024-05-24 at 19:11 +0200, Dan Shelton wrote:
> > > On Wed, 15 May 2024 at 23:46, Steve Dickson <steved@redhat.com> wrote=
:
> > > >
> > > > Hey!
> > > >
> > > > On 5/14/24 5:57 PM, Dan Shelton wrote:
> > > > > Hello!
> > > > >
> > > > > Solaris, Windows and libnfs NFSv4 clients support RFC2224 URLs, w=
hich
> > > > > 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 ea=
sier.
> > >
> >
> > 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.

There is another use case for URLs: Unicode characters in hostname and
path. Not really applicable in the US, but the french frog eaters and
CJKV (Chinese, Japanese, Korean, Vietnamese) would find that useful.

Ced
--=20
Cedric Blancher <cedric.blancher@gmail.com>
[https://plus.google.com/u/0/+CedricBlancher/]
Institute Pasteur