From owner-freebsd-arch@FreeBSD.ORG Tue Dec 2 19:51:43 2014 Return-Path: Delivered-To: arch@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 4FC97B64 for ; Tue, 2 Dec 2014 19:51:43 +0000 (UTC) Received: from st11p02mm-asmtp001.mac.com (st11p02mm-asmtpout001.mac.com [17.172.220.236]) (using TLSv1 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 1F158A37 for ; Tue, 2 Dec 2014 19:51:42 +0000 (UTC) Received: from fukuyama.hsd1.ca.comcast.net (unknown [73.162.13.215]) by st11p02mm-asmtp001.mac.com (Oracle Communications Messaging Server 7.0.5.33.0 64bit (built Aug 27 2014)) with ESMTPSA id <0NFZ006B80I39K70@st11p02mm-asmtp001.mac.com> for arch@FreeBSD.org; Tue, 02 Dec 2014 19:51:41 +0000 (GMT) X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:5.13.68,1.0.33,0.0.0000 definitions=2014-12-02_08:2014-12-02,2014-12-02,1970-01-01 signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 spamscore=0 suspectscore=0 phishscore=0 adultscore=0 bulkscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=7.0.1-1408290000 definitions=main-1412020170 Content-type: text/plain; charset=windows-1252 MIME-version: 1.0 (Mac OS X Mail 8.1 \(1993\)) Subject: Re: Disparity between /etc/services and /var/db/services.db From: Rui Paulo In-reply-to: <556364B6-EB7C-421F-B2FB-64A170611A56@gmail.com> Date: Tue, 02 Dec 2014 11:51:39 -0800 Content-transfer-encoding: quoted-printable Message-id: References: <6F3959BB-3B71-4515-B7BD-C1A640E8327A@gmail.com> <556364B6-EB7C-421F-B2FB-64A170611A56@gmail.com> To: Garrett Cooper X-Mailer: Apple Mail (2.1993) Cc: "freebsd-arch@freebsd.org" , Benjamin Kaduk X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 02 Dec 2014 19:51:43 -0000 On Dec 2, 2014, at 08:13, Garrett Cooper wrote: >=20 > On Dec 1, 2014, at 11:28, Benjamin Kaduk 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