From: Jeff Layton <jlayton@kernel.org>
To: Dan Shelton <dan.f.shelton@gmail.com>,
Linux NFS Mailing List <linux-nfs@vger.kernel.org>
Subject: Re: RFC2224 support in Linux /sbin/mount.nfs4?
Date: Sun, 26 May 2024 07:27:58 -0400 [thread overview]
Message-ID: <ee3805865e12f8ed2f82f7e99e33598f0bcc6667.camel@kernel.org> (raw)
In-Reply-To: <CAAvCNcCGhZ917yerEOMcEEj7+_Yz5by8en2F4Yr5zLk0iQEGjg@mail.gmail.com>
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, 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@kernel.org>
next prev parent reply other threads:[~2024-05-26 11:28 UTC|newest]
Thread overview: 11+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-05-14 21:57 RFC2224 support in Linux /sbin/mount.nfs4? Dan Shelton
2024-05-15 21:46 ` Steve Dickson
2024-05-24 17:11 ` Dan Shelton
2024-05-25 12:44 ` Steve Dickson
2024-05-26 11:27 ` Jeff Layton [this message]
2024-05-26 14:12 ` Martin Wege
2024-05-26 14:31 ` Jeff Layton
2024-05-27 5:16 ` Cedric Blancher
2024-05-29 3:02 ` Dan Shelton
2024-05-29 6:27 ` Christoph Hellwig
2024-05-29 13:52 ` Chuck Lever III
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=ee3805865e12f8ed2f82f7e99e33598f0bcc6667.camel@kernel.org \
--to=jlayton@kernel.org \
--cc=dan.f.shelton@gmail.com \
--cc=linux-nfs@vger.kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox