Re: Should we establish a new nfsdctl userland program?

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

 



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.
-- 
Jeff Layton <jlayton@xxxxxxxxxx>





[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