Received-SPF: pass (google.com: domain of linux-nfs+bounces-1448-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: <8a7bbc05b6515109692cb88ad68374d14fc01eca.camel@kernel.org>
 <CALXu0UcV0b8OvH7_05tD7+GRgoXRcp9fd1aXuHjtF2OBDPmSJw@mail.gmail.com> <66892D4F-4721-48E5-A088-BD75500275AD@oracle.com>
In-Reply-To: <66892D4F-4721-48E5-A088-BD75500275AD@oracle.com>
From: Dan Shelton <dan.f.shelton@gmail.com>
Date: Fri, 26 Jan 2024 01:50:34 +0100
Message-ID: <CAAvCNcA4x1vR2Bh0vTy+kc7tK0t7sdM0JPJa5-XfLhD+-mLQTg@mail.gmail.com>
Subject: Re: Should we establish a new nfsdctl userland program?
To: Chuck Lever III <chuck.lever@oracle.com>
Cc: Cedric Blancher <cedric.blancher@gmail.com>, Jeff Layton <jlayton@kernel.org>, 
	Lorenzo Bianconi <lorenzo.bianconi@redhat.com>, NeilBrown <neilb@suse.com>, 
	Dai Ngo <dai.ngo@oracle.com>, Olga Kornievskaia <olga.kornievskaia@gmail.com>, 
	Tom Talpey <tom@talpey.com>, Linux NFS Mailing List <linux-nfs@vger.kernel.org>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

On Thu, 25 Jan 2024 at 21:25, Chuck Lever III <chuck.lever@oracle.com> wrot=
e:
>
>
>
> > On Jan 25, 2024, at 2:54=E2=80=AFPM, Cedric Blancher <cedric.blancher@g=
mail.com> wrote:
> >
> > On Thu, 25 Jan 2024 at 20:41, Jeff Layton <jlayton@kernel.org> wrote:
> >>
> >> The existing rpc.nfsd program was designed during a different time, wh=
en
> >> we just didn't require that much control over how it behaved. It's
> >> klunky to work with.
> >>
> >> In a response to Chuck's recent RFC patch to add knob to disable
> >> READ_PLUS calls, I mentioned that it might be a good time to make a
> >> clean break from the past and start a new program for controlling nfsd=
.
> >>
> >> Here's what I'm thinking:
> >>
> >> Let's build a swiss-army-knife kind of interface like git or virsh:
> >>
> >> # nfsdctl stats                 <--- fetch the new stats that got merg=
ed
> >> # nfsdctl add_listener          <--- add a new listen socket, by addre=
ss or hostname
> >
> > Absolutely NOT "hostname". Please do not repeat the mistake AGAIN of
> > separating "host name" and "TCP port", as they are both required to
> > find the server. Every 10 or 15 years the same mistake is made by the
> > next generation of software engineers.
>
> I don't see how this is a mistake.
>
> >   port
> >      The port number to connect to. Most schemes designate
> >      protocols that have a default port number. Another port number
> >      may optionally be supplied, in decimal, separated from the
> >      host by a colon. If the port is omitted, the colon is as well.
>
> NFS has a default port number. Thus, even RFC 1738 states that
> "hostname" is just fine. It means "DNS label and default port".
>
> Most usage scenarios will prefer the shorthand of leaving off the
> port. So engineers seem to be designing interfaces for the most
> common usage, don't you think?

The most common usage? For small shops that might apply, but not for
big hosters where IPv4 addresses are a scarce resource.
>
>
> > https://datatracker.ietf.org/doc/html/rfc1738 clearly defined
> > "hostport", and that is what should be used here.
>
> RFC 1738 was published very clearly before the widespread use of
> IPv6 addresses,

Read below, you need [ and ] for IPv6 addresses, or be in parser hell.

> which use a : to separate the components of an
> IP address.

I think you take the syntax part too seriously, and not Cedric's
message: Address and port should be specified together, as they are
required to be used together to create the socket. It's part of the
address information.

Instead of fighting over syntax (hostname@port, hostname:port, ...) it
should seriously be considered to include the port.

Also, it might be good for hosters to allow more than one nfsd
instance with seperate exports file, each running on its own
address/port combination. And not force them to use a VM to bloat
resources.

> Certainly the add_listener subcommand can take a port, but there's
> plenty of room to add that in other ways.
>
> For example, we might want:
>
> # nfsdctl add_listener
>
>    xprt <udp|tcp|rdma>
>
>    host <DNS label>  |   addr <IPv4 or IPv6 address>
>
> and optionally
>
>    port <listener port>

Nope. Just hostname:port or hostname@port. For raw IPv6 addresses you
have to use square brackets anyway, or end up in parser hell.

Dan
--=20
Dan Shelton - Cluster Specialist Win/Lin/Bsd