Subject: Re: Making file-based getXent quicker
To: Darren Reed <darrenr@NetBSD.org>
From: Brian Ginsbach <ginsbach@NetBSD.org>
List: tech-userlevel
Date: 03/20/2006 03:35:11
On Sun, Mar 19, 2006 at 08:41:14PM +0000, Darren Reed wrote:
> 
> In a discussion about how NetBSD opens and closes nls files way too
> often, it was brought up that there are similar problems with the
> name-number files like /etc/services and /etc/protocols.
> 
> So the problem is, what to do about it?  How can they be made quicker?

But how often does a program really open services and/or protocols?
Don't most things that need this information do it once at startup?
The worst "offender" may be getaddrinfo(3) but my memory is a bit
hazy.  Even this should pretty much be at startup only.

> 
> One idea I'd like to discuss is what about using a shared memory map
> that is published by a daemon ?  If the daemon isn't present or the
> map is missing, fall back to the "slow approach."

Sounds a lot like Unified Name Service in IRIX, a.k.a. nsd(1M).
From the IRIX nsd(1M) man page:

     The Unified Name Service (UNS) provides a generic interface to network
     lookup services.  The daemon provides a filesystem front end to the name
     service namespace, and maintains local cache files.  The services that
     the nsd daemon supports are NIS - the Network Information Service, DNS -
     the Domain Name Service, local configuration files, MDBM, NDBM, and DB -
     local hash files, LDAP - Lightweight Directory Access Protocol.

> 
> The daemon would use kqueue events to know when it should refresh the
> cache as changes to the files are made - this won't work if /etc or the
> mount point the files come from isn't local.
> 
> The file created by the daemon would live in /var/run, perhaps a
> /var/run/nscd.map.
> 
> This file would need to be opened and read only once in the lifetime
> of a program.  The shared memory segment would act as an in-core
> database (maybe 8k-16k) that get*name/get*by* would copy data out
> of before returning it to the caller.  Some use of locking would
> be required to keep people out while it is being updated.
> 
> Unfortunately I can't think of a better name for it than nscd.

nsd?

> 
> What this solution means in the context of NIS/LDAP serving these
> databases hasn't yet been considered yet.  But in a local files
> approach, I can see the following being cached:
> 
> /etc/services
> /etc/protocols
> /etc/hosts
> /etc/passwd
> /etc/rpc
> 
> Other files?

/etc/groups
/etc/netgroups

Pretty much anything that one finds in nsswitch.conf(5) would seem to be
fair game.

> 
> Thoughts?  Comments?  Suggestions?  Flames?

Yes, but I'll follow up with these off-list.