On Fri, 2024-01-26 at 08:11 +1100, NeilBrown wrote: > On Fri, 26 Jan 2024, Jeff Layton 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. > > How is it clunky? > > rpc.nfsd > > that starts the service. > > rpc.nfsd 0 > > that stops the service. > > Ok, not completely elegant. Maybe > > nfsdctl start > nfsdctl stop > > would be better. > It's clunky if you have to script around it. Mostly it's an issue for people doing clustering and that sort of thing. > > > > 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 Sorry, not READ_PLUS calls here, I meant splice_reads... > > 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 > > Sure the "git" style would use > > nfsdctl version 3 on > nfsdctl threads 128 > I like following git's example syntactically. > Apart from "stats", "start", "stop", I suspect that we developers would > be the only people to actually use this functionality. > Agreed, maybe alongside higher orchestration like containerization or clustering tech. > Until now, > echo > /proc/sys/nfsd/foo > has been enough for most tweeking. Having a proper tool would likely > lower the barrier to entry, which can only be a good thing. > I think so too. Also, we don't really have that option with netlink. We need some sort of tool to drive the new interfaces. > > > > 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. > > systemd doesn't need a fallback. Systemd always activates > nfs-server.service. We just need to make sure the installed > nfs-server.service matches the installed tools, and as they are > distributed as parts of the same package, that should be trivial. > The problem is the transition period. There will come a time where people will have kernels that don't support the new netlink interface, but newer userland. We could teach nfsdctl to work with nfsdfs, but I'd rather it just bail out and say "Sorry, you have to use rpc.nfsd on this old kernel". Maybe we don't need to worry about plumbing that logic into the systemd service though, and just having distros do a hard cutover at some point makes more sense. > > > > 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. > > Agreed. > > > > > 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 > > > > 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)? > > /usr/lib/git-core (on my laptop) has 168 entries. Only 29 of them are > NOT symlinks to 'git'. > > While I do like the "tool command args" interface, and I like the option > of adding commands by simply creating drop-in tools, I think that core > functionality should go in the core tool. > So: "one big binary" please - with call-out functionality if anyone can > be bothered implementing it. > Ok, sounds good to me. > > > > 2/ should it automagically read in nfs.conf? (I tend to think it should, > > but we might want an option to disable that) > > Absolutely definitely. I'm not convinced we need an option to disable > config, but allowing options to over-ride specific configs is sensible. > > Most uses of this tool would come from nfs-server.service which would > presumably call > nfsdctl start > which would set everything based on the nfs.conf and thus start the > server. And > nfsdctl stop > which would set the number of threads to zero. > Sensible. > > > > 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. > > It might be sensible to have "set max-threads" which doesn't actually > start the service. > I would really REALLY like a dynamic thread pool. It would start at 1 > (or maybe 2) and grow on demand up to the max, and idle threads > (inactive for 30 seconds?) would exit. We could then default the max to > some function of memory size and people could mostly ignore the > num-threads setting. > > I don't have patches today, but if we are re-doing the interfaces I > would like us to plan the interfaces to support a pool rather than a > fixed number. > I like that idea too. A dynamic threadpool would be very nice to have. Since we're dreaming: Maybe we can set "threads" to a specific value (-1?) that makes it start the pool at "min_threads" and dynamically size the pool up to "max_threads" with the load. > > > > I'm sure other questions will arise as we embark on this too. > > > > Thoughts? Anyone have objections to this idea? > > I think this is an excellent question to ask. As you say it is a long > time since rpc.nfsd was created, and it has grown incrementally rather > then being clearly designed. Thanks. I think this is something that has the potential to really make server administration simpler. I also wouldn't mind a readline-style shell interface if you just run nfsdctl without arguments. Like: # nfsdctl nfsdctl> threads 128 nfsdctl> version 3 off nfsdctl> start nfsdctl> ^d ...but that could be added later too. -- Jeff Layton <jlayton@xxxxxxxxxx>
