On 3/4/21 8:01 AM, J. Bruce Fields wrote:
On Thu, Mar 04, 2021 at 08:42:24AM -0500, Steve Dickson wrote:
On 3/3/21 4:54 PM, J. Bruce Fields wrote:
On Wed, Mar 03, 2021 at 04:22:28PM -0500, Steve Dickson wrote:
Hey!
On 3/3/21 10:23 AM, J. Bruce Fields wrote:
On Tue, Mar 02, 2021 at 05:33:23PM -0500, Steve Dickson wrote:
On 2/24/21 3:30 PM, J. Bruce Fields wrote:
On Fri, Feb 19, 2021 at 03:08:08PM -0500, Steve Dickson wrote:
nfsv4.exportd is a daemon that will listen for only v4 mount upcalls.
The idea is to allow distros to build a v4 only package
which will have a much smaller footprint than the
entire nfs-utils package.
exportd uses no RPC code, which means none of the
code or arguments that deal with v3 was ported,
this again, makes the footprint much smaller.
How much smaller?
Will a bit smaller... but a number of daemons like nfsd[cld,clddb,cldnts]
need to also come a long.
Could we get some numbers?
Looks like nfs-utils in F33 is about 1.2M:
$ rpm -qi nfs-utils|grep ^Size
Size : 1243512
$ strip utils/mountd/mountd
$ ls -lh utils/mountd/mountd
-rwxrwxr-x. 1 bfields bfields 128K Mar 3 10:12 utils/mountd/mountd
$ strip utils/exportd/exportd
$ ls -lh utils/exportd/exportd
-rwxrwxr-x. 1 bfields bfields 106K Mar 3 10:12 utils/exportd/exportd
So replacing mountd by exportd saves us about 20K out of 1.2M. Is it
worth it?
In smaller foot print I guess I meant no v3 daemons, esp rpcbind.
The rpcbind rpm is 120K installed, so if the new v4-only rpm has no
dependency on rpcbind then we save 120K.
The point with rpcbind is it not going to be started which means
it not opening up listening connection that may never be used.
This has pissed of people for years! :-)
OK, but we can do that without replacing mountd and changing the way
everyone installs nfs-utils and runs the nfs server.
>
> --b.
>
Yes, but then people get involved. The announcement of exportd was the
tech highlight of my week. It's not about the size, it's about how
distros package the tools, documentation, and configuration complexity.
Taking these one at a time:
If it were up to me, everyone would run Arch linux with NFS systemd
service files I wrote myself. These service files would pretend that NFS
v.3 was long forgotten. Unfortunately, I work in a large organization
with other people and don't get to make those calls. We run Ubuntu and
RHEL/CentOS, and the systemd service files are configured to launch
rpcbind as a dependent service. That's a problem because the local
Information Security Office sees rpcbind as a dangerous cancer and will
automatically quarantine any machine advertising this service. I've
worked through the spaghetti ensemble of service units provided by
Canonical which launch NFS services in order to attempt to undo the
rpcbind dependency, but it's a pain in the ass. If NFS v.3 isn't an
option, the distro supplied service files will necessarily be required
to behave, too.
If the NFS documentation were superlative, this might be less of a
problem, but the current instantiation of NFS is saddled with decades of
technical debt, out of date documentation and some new features aren't
even documented (we've even discussed this on this list). I'm still
trying to figure out how people know how to set up pNFS, for example.
NFS v4 is sufficiently different from v3 that the preponderance of old
information on the Internet is confusing and contradictory. If the
daemon name is different, that's an immediate and obvious tip off that
you're looking at out of date information. The people referencing
exportd are the ones to pay attention to.
Looking at one of my Ubuntu 18.04 server installs, there's configuration
information in the systemd unit files, there's configuration information
in /etc/default, and elsewhere. If I set
RPCMOUNTDOPTS="--manage-gids -N 2 -N 3 -u"
in /etc/default/nfs-kernel-server, does that actually do anything? Who
knows? (Actually, if you dig through everything related in
/lib/systemd/system, it does at least read this file.) Runing tcpdump
and tracing the packets should not be the solution to every
configuration question. Any simplification of this is welcome, even if
the resulting code is 128K *larger*.
Also, I'm guessing NFS would see wider adoption if there were a
simplified v.4 only packaging option. Just sayin'.
