Re: Should we establish a new nfsdctl userland program?

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 




> On Jan 25, 2024, at 2:54 PM, Cedric Blancher <cedric.blancher@xxxxxxxxx> wrote:
> 
> On Thu, 25 Jan 2024 at 20:41, Jeff Layton <jlayton@xxxxxxxxxx> wrote:
>> 
>> The existing rpc.nfsd program was designed during a different time, when
>> 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 merged
>> # nfsdctl add_listener          <--- add a new listen socket, by address 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?


> 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, which use a : to separate the components of an
IP address.

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>

If port is not specified, the default port for the xprt type
is assumed. (eg, 2049 or 20049)

Eventually, also:

# nfsdctl del_listener ... with similar arguments

--
Chuck Lever






[Index of Archives]     [Linux Filesystem Development]     [Linux USB Development]     [Linux Media Development]     [Video for Linux]     [Linux NILFS]     [Linux Audio Users]     [Yosemite Info]     [Linux SCSI]

  Powered by Linux