Re: Should we establish a new nfsdctl userland program?

[Lorenzo Bianconi <lorenzo.bianconi@redhat.com>]

[-- Attachment #1: Type: text/plain, Size: 3882 bytes --]

> On Fri, 2024-02-02 at 18:08 +0100, Lorenzo Bianconi 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
> > > # nfsdctl set v3 on		<--- enable NFSv3
> > > # nfsdctl set splice_read off	<--- disable splice reads (per Chuck's recent patch)
> > > # nfsdctl set threads 128	<--- spin up the threads
> > > 
> > > We could start with just the bare minimum for now (the stats interface),
> > > and then expand on it. Once we're at feature parity with rpc.nfsd, we'd
> > > want to have systemd preferentially use nfsdctl instead of rpc.nfsd to
> > > start and stop the server. systemd will also need to fall back to using
> > > rpc.nfsd if nfsdctl or the netlink program isn't present.
> > > 
> > > Note that I think this program will have to be a compiled binary vs. a
> > > python script or the like, given that it'll be involved in system
> > > startup.
> > > 
> > > It turns out that Lorenzo already has a C program that has a lot of the
> > > plumbing we'd need:
> > > 
> > >     https://github.com/LorenzoBianconi/nfsd-netlink
> > 
> > This is something I developed just for testing the new interface but I agree we
> > could start from it.
> > 
> > Regarding the kernel part I addressed the comments I received upstream on v6 and
> > pushed the code here [0].
> > How do you guys prefer to proceed? Is the better to post v7 upstream and continue
> > the discussion in order to have something usable to develop the user-space part or
> > do you prefer to have something for the user-space first?
> > I do not have a strong opinion on it.
> > 
> > Regards,
> > Lorenzo
> > 
> > [0] https://github.com/LorenzoBianconi/nfsd-next/tree/nfsd-next-netlink-new-cmds-public-v7
> > 
> > 
> 
> My advice?
> 
> Step back and spend some time working on the userland bits before
> posting another revision. Experience has shown that you never realize
> what sort of warts an interface like this has until you have to work
> with it.
> 
> You may find that you want to tweak it some once you do, and it's much
> easier to do that before we merge anything. This will be part of the
> kernel ABI, so once it's in a shipping kernel, we're sort of stuck with
> it.
> 
> Having a userland program ready to go will allow us to do things like
> set up the systemd service for this too, which is primarily how this new
> program will be called.

I agree on it. In order to proceed I guess we should define a list of
requirements/expected behaviour on this new user-space tool used to
configure nfsd. I am not so familiar with the user-space requirements
for nfsd so I am just copying what you suggested, something like:

$ nfsdctl stats                                                 <--- fetch the new stats that got merged
$ nfsdctl xprt add proto <udp|tcp> host <host> [port <port>]    <--- add a new listen socket, by address or hostname
$ nfsdctl proto v3.0 v4.0 v4.1                                  <--- enable NFSv3 and v4.1
$ nfsdctl set threads 128                                       <--- spin up the threads

Can we start from [0] to develop them?

Regards,
Lorenzo

[0] https://github.com/LorenzoBianconi/nfsd-netlink

> -- 
> Jeff Layton <jlayton@kernel.org>
> 

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 228 bytes --]