Received-SPF: pass (google.com: domain of linux-nfs+bounces-1718-linux.lists.archive=gmail.com@vger.kernel.org designates 2604:1380:45d1:ec00::1 as permitted sender) client-ip=2604:1380:45d1:ec00::1;
Date: Fri, 2 Feb 2024 18:08:38 +0100
From: Lorenzo Bianconi <lorenzo.bianconi@redhat.com>
To: Jeff Layton <jlayton@kernel.org>
Cc: Chuck Lever <chuck.lever@oracle.com>, NeilBrown <neilb@suse.com>,
	Dai Ngo <dai.ngo@oracle.com>,
	"olga.kornievskaia" <olga.kornievskaia@gmail.com>,
	Tom Talpey <tom@talpey.com>, linux-nfs <linux-nfs@vger.kernel.org>
Subject: Re: Should we establish a new nfsdctl userland program?
Message-ID: <Zb0hlnQmgVikeNpi@lore-rh-laptop>
References: <8a7bbc05b6515109692cb88ad68374d14fc01eca.camel@kernel.org>
Precedence: bulk
MIME-Version: 1.0
Content-Type: multipart/signed; micalg=pgp-sha512;
	protocol="application/pgp-signature"; boundary="Y4fqAr61eeYDETl5"
Content-Disposition: inline
In-Reply-To: <8a7bbc05b6515109692cb88ad68374d14fc01eca.camel@kernel.org>


--Y4fqAr61eeYDETl5
Content-Type: text/plain; charset=iso-8859-1
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable

> 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.
>=20
> 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.
>=20
> Here's what I'm thinking:
>=20
> Let's build a swiss-army-knife kind of interface like git or virsh:
>=20
> # nfsdctl=A0stats			<--- fetch the new stats that got merged
> # nfsdctl add_listener		<--- add a new listen socket, by address or hostn=
ame
> # nfsdctl set v3 on		<--- enable NFSv3
> # nfsdctl set splice_read off	<--- disable splice reads (per Chuck's rece=
nt patch)
> # nfsdctl set threads 128	<--- spin up the threads
>=20
> 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.
>=20
> 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.
>=20
> It turns out that Lorenzo already has a C program that has a lot of the
> plumbing we'd need:
>=20
>     https://github.com/LorenzoBianconi/nfsd-netlink

This is something I developed just for testing the new interface but I agre=
e we
could start from it.

Regarding the kernel part I addressed the comments I received upstream on v=
6 and
pushed the code here [0].
How do you guys prefer to proceed? Is the better to post v7 upstream and co=
ntinue
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

>=20
> I think it might be good to clean up the interface a bit, build a
> manpage and merge that into nfs-utils.
>=20
> Questions:
>=20
> 1/ one big binary, or smaller nfsdctl-* programs (like git uses)?
>=20
> 2/ should it automagically read in nfs.conf? (I tend to think it should,
> but we might want an option to disable that)
>=20
> 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.
>=20
> I'm sure other questions will arise as we embark on this too.
>=20
> Thoughts? Anyone have objections to this idea?
> --=20
> Jeff Layton <jlayton@kernel.org>
>=20

--Y4fqAr61eeYDETl5
Content-Type: application/pgp-signature; name="signature.asc"

-----BEGIN PGP SIGNATURE-----

iHUEABYKAB0WIQTquNwa3Txd3rGGn7Y6cBh0uS2trAUCZb0hkwAKCRA6cBh0uS2t
rM+3AP4v3+P/FFC/bLjALNfUYitWBR12o0xfPHLw1+JXzqw3vgEAl36TAQSI1HpS
KKFMk1xIAE3pUhFwL1CcgU1Dhl5y4AM=
=sCuO
-----END PGP SIGNATURE-----

--Y4fqAr61eeYDETl5--