Disparity between /etc/services and /var/db/services.db

Rui Paulo rpaulo at me.com
Tue Dec 2 19:51:43 UTC 2014


On Dec 2, 2014, at 08:13, Garrett Cooper <yaneurabeya at gmail.com> wrote:
> 
> On Dec 1, 2014, at 11:28, Benjamin Kaduk <kaduk at MIT.EDU> wrote:
> 
>> On Mon, 1 Dec 2014, Garrett Cooper wrote:
>> 
>>> $ ls -l /scratch/2/etc/services /scratch/2/var/db/services.db
>>> -rw-r--r--  1 ngie  wheel    86802 Nov 27 02:23 /scratch/2/etc/services
>>> -rw-r--r--  1 ngie  wheel  2097920 Nov 27 02:23 /scratch/2/var/db/services.db
>> 
>> One's a text file and the other a Berkeley DB file ... I wouldn't expect
>> them to be the same size.
> 
> Shoot. I didn’t mean for this message to get sent out without a lot of context. For that I apologize...
> 
> Basically what I was going to comment on was the fact that the .db file was so large, and by adjusting the number of entries I was able to reduce the size of the file by 4 (it’s bloated by a couple thousand):
> 
> From usr.sbin/services_mkdb/services_mkdb.c:
> 
> 70 HASHINFO hinfo = {
> 71         .bsize = 256,
> 72         .ffactor = 4,
> 73         .nelem = 32768,
> 74         .cachesize = 1024,
> 75         .hash = NULL,
> 76         .lorder = 0
> 77 };

I doubt you'll find any history without contacting the original author (ume@).  If I had to guess, I think this was a premature optimisation.  The database just needs to contain a two level hash up: port number and service number.  If you can prove that reducing nelem size doesn't cause a performance regression, then we could change it.  4MB is way too much on an embedded system.

--
Rui Paulo





More information about the freebsd-arch mailing list