Skip site navigation (1)Skip section navigation (2)
Date:      Tue, 02 Dec 2014 11:51:39 -0800
From:      Rui Paulo <rpaulo@me.com>
To:        Garrett Cooper <yaneurabeya@gmail.com>
Cc:        "freebsd-arch@freebsd.org" <arch@FreeBSD.org>, Benjamin Kaduk <kaduk@MIT.EDU>
Subject:   Re: Disparity between /etc/services and /var/db/services.db
Message-ID:  <D4099F51-E574-47E6-95BB-D4F6298ADBCE@me.com>
In-Reply-To: <556364B6-EB7C-421F-B2FB-64A170611A56@gmail.com>
References:  <6F3959BB-3B71-4515-B7BD-C1A640E8327A@gmail.com> <alpine.GSO.1.10.1412011428160.23489@multics.mit.edu> <556364B6-EB7C-421F-B2FB-64A170611A56@gmail.com>

next in thread | previous in thread | raw e-mail | index | archive | help
On Dec 2, 2014, at 08:13, Garrett Cooper <yaneurabeya@gmail.com> wrote:
>=20
> On Dec 1, 2014, at 11:28, Benjamin Kaduk <kaduk@MIT.EDU> wrote:
>=20
>> On Mon, 1 Dec 2014, Garrett Cooper wrote:
>>=20
>>> $ 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
>>=20
>> One's a text file and the other a Berkeley DB file ... I wouldn't =
expect
>> them to be the same size.
>=20
> Shoot. I didn=92t mean for this message to get sent out without a lot =
of context. For that I apologize...
>=20
> 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=92s bloated by a couple thousand):
>=20
> =46rom usr.sbin/services_mkdb/services_mkdb.c:
>=20
> 70 HASHINFO hinfo =3D {
> 71         .bsize =3D 256,
> 72         .ffactor =3D 4,
> 73         .nelem =3D 32768,
> 74         .cachesize =3D 1024,
> 75         .hash =3D NULL,
> 76         .lorder =3D 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






Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?D4099F51-E574-47E6-95BB-D4F6298ADBCE>