Subject: Re: Making file-based getXent quicker
To: Darren Reed <darrenr@NetBSD.org>
From: Brian Ginsbach <ginsbach@NetBSD.org>
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
> 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.
> 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:
> Other files?
Pretty much anything that one finds in nsswitch.conf(5) would seem to be
> Thoughts? Comments? Suggestions? Flames?
Yes, but I'll follow up with these off-list.