From: Enrico Weigelt [mailto:weigelt@xxxxxxxx]
Sent: Monday, May 26, 2008 2:11 PM
To: linux-nfs@xxxxxxxxxxxxxxx
Subject: Re: portmap -> map db entirely in filesystem
* Chuck Lever <chuck.lever@xxxxxxxxxx> wrote:
Well, first of all we are moving away from portmap these days since
we
need to support IPv6. We currently have an rpcbind implementation
that is ported from Solaris.
I had a look at it a few days ago ... far too fat for me.
If you really need Ipv6 support on portmap, let's just do it.
Shouldn't be such a big job.
Like everything else in the modern NFS world, the new versions of the
rpcbind protocol are more complex than the simpler older versions.
Many common implementations of rpcbind clients require the server to
support at least rpcbindv3 before they will connect to an RPC service
via AF_INET6.
So if we want a reasonable level of interoperability, you will need to
implement at least rpcbindv3 support, which means it has to support TI-
RPC and netconfig and all the rest. You will end up re-implementing
rpcbind in portmapper... so what exactly is the point?
But it would make sense to keep the rpcbind service completely in
the kernel.
And move more bloat into the kernel ? Isn't it big enough yet ?
We have some user space NFSD implementations, but the main Linux NFSD/
NLM implementation is kernel-based. That's because even though it can
be done in user space, there are some palpable advantages to having
NFSD and NLM in the kernel.
My point is there are also advantages to putting rpcbind in the
kernel, even though, yes, you can do it in user space adequately.
That way the kernel RPC services could register with the rpcbind
database directly, and we wouldn't have to worry about reregistering
running RPC services because of a daemon restart.
Wouldn't it be easier to just fix the portmapper ?
How do you prevent a user space daemon from being killed during OOM or
crashing because of a bug or a sysadmin's finger slip?
rpcbind already has warm-start built in, by the way. Again, we
already have something that does the job, so I'm hard pressed to
understand why we should bother with fixing portmapper.
There's no need to involve permanent storage for rpcbind.
There is even no need to have it running all the time, start on
demand is enough for some workloads (eg. in embedded/smalldev
environments)
Exactly... a kernel-provided service would not take any resources
(other than a little memory) unless called. It would not even require
an init script or xinet.d configuration to start it. So a kernel
rpcbind service would be more ideal for an embedded deployment that
either daemon in user space.
Note that portmapper today does not support warm-start, it stores
state in memory only. So you would have to hack it to store RPC
service registrations in a file somewhere if you wanted a start-on-
demand service based on portmapper.
--
Chuck Lever
chuck[dot]lever[at]oracle[dot]com
--
To unsubscribe from this list: send the line "unsubscribe linux-nfs" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
