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
--
---------------------------------------------------------------------
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/
---------------------------------------------------------------------
* Chuck Lever <[email protected]> wrote:
Hi,
> 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.
> 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.
> 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 ?
> 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)
> 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.
> (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
--
---------------------------------------------------------------------
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/
---------------------------------------------------------------------
On May 13, 2008, at 12:58 PM, Enrico Weigelt wrote:
> 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.
> 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
> --
> ---------------------------------------------------------------------
> 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
On Tue, May 13, 2008 at 03:30:42PM -0700, Chuck Lever wrote:
> On May 13, 2008, at 12:58 PM, Enrico Weigelt wrote:
>> 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.
Sounds sensible to me....--b.
>
> 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.
>
>> 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
>> --
>> ---------------------------------------------------------------------
>> 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