Re: Should we establish a new nfsdctl userland program?

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

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

> 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

> 
> I think it might be good to clean up the interface a bit, build a
> manpage and merge that into nfs-utils.
> 
> Questions:
> 
> 1/ one big binary, or smaller nfsdctl-* programs (like git uses)?
> 
> 2/ should it automagically read in nfs.conf? (I tend to think it should,
> but we might want an option to disable that)
> 
> 3/ should "set threads" activate the server, or just set a count, and
> then we do a separate activation step to start it? If we want that, then
> we may want to twiddle the proposed netlink interface a bit.
> 
> I'm sure other questions will arise as we embark on this too.
> 
> Thoughts? Anyone have objections to this idea?
> -- 
> Jeff Layton <jlayton@kernel.org>
> 

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