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