portmap -> map db entirely in filesystem
Subsystems (2)
Hi folks,
while working on portmap, I was thinking about moving the entire mapping table to the filesystem: one file per record.
Benefits:
* allows much simpler code: no internal maptable and load/store logic - just simple file IO (even limited to REST)
* external programs can directly manipulate the map db, w/o goint through portmap itself
* several portmap's (eg. for serving on separate sockets or different security domains) can easily share the same map.
* less process memory consumption of portmap (on larger maps)
Drawbacks:
* a bit slower, more IO traffic
* we have to rethink chroot'ing
What do you think about this ?
cu
Signature · 8 lines
--------------------------------------------------------------------- Enrico Weigelt == metux IT service - http://www.metux.de/ --------------------------------------------------------------------- Please visit the OpenSource QM Taskforce: http://wiki.metux.de/public/OpenSource_QM_Taskforce Patches / Fixes for a lot dozens of packages in dozens of versions: http://patches.metux.de/ ---------------------------------------------------------------------
A message that is not in the archive (sent off-list or not yet received): [email protected]
Quoted 4 lines · Enrico Weigelt
Hi folks,
while working on portmap, I was thinking about moving the entire mapping table to the filesystem: one file per record.
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.
But it would make sense to keep the rpcbind service completely in the kernel. That way the kernel RPC services could register with the rpcbind database directly, and we wouldn't have to worry about re-registering running RPC services because of a daemon restart.
There's no need to involve permanent storage for rpcbind. Once the system reboots the database is empty and must be repopulated as RPC services are restarted.
Local user-space RPC services might then register via an ioctl() (or other special interface) instead of an actual RPC. That way we could gate RPC service registration with actual security capabilities.
Quoted 12 lines
Benefits:
* allows much simpler code: no internal maptable and load/store logic - just simple file IO (even limited to REST)
* external programs can directly manipulate the map db, w/o goint through portmap itself
* several portmap's (eg. for serving on separate sockets or different security domains) can easily share the same map.
* less process memory consumption of portmap (on larger maps)Drawbacks:
Quoted 21 lines
* a bit slower, more IO traffic
* we have to rethink chroot'ingWhat do you think about this ?
cu
Signature · 12 lines
--------------------------------------------------------------------- Enrico Weigelt == metux IT service - http://www.metux.de/ --------------------------------------------------------------------- Please visit the OpenSource QM Taskforce: http://wiki.metux.de/public/OpenSource_QM_Taskforce Patches / Fixes for a lot dozens of packages in dozens of versions: http://patches.metux.de/ --------------------------------------------------------------------- -- To unsubscribe from this list: send the line "unsubscribe linux-nfs" in the body of a message to [email protected] More majordomo info at http://vger.kernel.org/majordomo-info.html
--
Chuck Lever
chuck[dot]lever[at]oracle[dot]com
Quoted 6 lines · Chuck Lever
Quoted 4 lines · Enrico Weigelt
Hi folks,
while working on portmap, I was thinking about moving the entire mapping table to the filesystem: one file per record.
Quoted 8 lines
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.
But it would make sense to keep the rpcbind service completely in the kernel. That way the kernel RPC services could register with the rpcbind database directly, and we wouldn't have to worry about re- registering running RPC services because of a daemon restart.
Sounds sensible to me....--b.
Quoted 54 lines
There's no need to involve permanent storage for rpcbind. Once the system reboots the database is empty and must be repopulated as RPC services are restarted.
Local user-space RPC services might then register via an
ioctl()(or other special interface) instead of an actual RPC. That way we could gate RPC service registration with actual security capabilities.Quoted 12 lines
Benefits:
* allows much simpler code: no internal maptable and load/store logic - just simple file IO (even limited to REST)
* external programs can directly manipulate the map db, w/o goint through portmap itself
* several portmap's (eg. for serving on separate sockets or different security domains) can easily share the same map.
* less process memory consumption of portmap (on larger maps)Drawbacks:
Quoted 22 lines
* a bit slower, more IO traffic
* we have to rethink chroot'ingWhat do you think about this ?
cu
Signature · 13 lines
--------------------------------------------------------------------- Enrico Weigelt == metux IT service - http://www.metux.de/ --------------------------------------------------------------------- Please visit the OpenSource QM Taskforce: http://wiki.metux.de/public/OpenSource_QM_Taskforce Patches / Fixes for a lot dozens of packages in dozens of versions: http://patches.metux.de/ --------------------------------------------------------------------- -- To unsubscribe from this list: send the line "unsubscribe linux-nfs" in the body of a message to [email protected] More majordomo info at http://vger.kernel.org/majordomo-info.html--
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 [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
* Chuck Lever <[email protected]> wrote:
Hi,
Quoted 3 lines
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.
Quoted 2 lines
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 ?
Actually, I'm working on making the kernel smaller, moving several things into userspace.
Quoted 3 lines
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 ?
Quoted 1 line
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)
Quoted 1 line
Local user-space RPC services might then register via an
ioctl()
Oh no, please no more ioctl()'s. We should start getting rid of that old relics.
Quoted 1 line
(or other special interface) instead of an actual RPC.
And require an rewrite of each RPC service ? What a funny idea ;-o Making a originally IP-based service locally dependent sounds like a strange step back to me ...
cu
Signature · 8 lines
--------------------------------------------------------------------- Enrico Weigelt == metux IT service - http://www.metux.de/ --------------------------------------------------------------------- Please visit the OpenSource QM Taskforce: http://wiki.metux.de/public/OpenSource_QM_Taskforce Patches / Fixes for a lot dozens of packages in dozens of versions: http://patches.metux.de/ ---------------------------------------------------------------------