Subject: Re: vgrindefs.db size ?
To: Jaromír Dolecek <dolecek@ics.muni.cz>
From: Greg A. Woods <woods@weird.com>
List: tech-userlevel
Date: 01/28/2001 15:26:15
[ On Sunday, January 28, 2001 at 17:25:11 ( +0100), Jaromír Dolecek wrote: ]
> Subject: Re: vgrindefs.db size ?
>
> Jim Wise wrote:
> > Modified Files:
> > 	basesrc/distrib/sets/lists/base: mi
> > 
> > Log Message:
> > Move vgrinddefs.db to base-groff-share.
> > 
> > Now that our db(3) can do byte-swapping, should this be in misc?
> 
> This made me look at /usr/share/misc/vgrindefs.db and I noticed
> it's 500KB whereas the source file (/usr/share/misc/vgrindefs) is
> approx. 7KB big. This is quite surprising, does anyone khow come
> it's like that ? Is the format used by cap_mkdb/getcap() so
> space-hungry ?

First of all at least half that space is due to the fact that the
installed copy is a plain *copy*.  DB (and dbm) files are often sparse
files and they don't copy well.  Don't look at the size in bytes, which
is simply and indicator of where the end fo the file is.  Look instead
at the size in sectors (or kilobytes):

	$ ls -s /NetBSD-obj.i386/usr.bin/vgrind/vgrindefs.src.db 
	592 /backups/NetBSD-obj.i386/usr.bin/vgrind/vgrindefs.src.db

	$ ls -s /usr/share/misc/vgrindefs.db  
	1056 /usr/share/misc/vgrindefs.db

If the installed copy had been made with some tool that preserved holes
in files, such as pax or restore, then it would be smaller.  Perhaps
'install' should try to preserve holes too, or at least not write blocks
of all NUL bytes (which is really all pax and restore do)....

Secondly, it is already in /usr/share, so certainly it should be machine
independent.  I don't know if it belongs in the misc set or not though.

Personally I'd rather create all of the db files at installation time
and not have them on the install media in any set!  ;-)

-- 
							Greg A. Woods

+1 416 218-0098      VE3TCP      <gwoods@acm.org>      <robohack!woods>
Planix, Inc. <woods@planix.com>; Secrets of the Weird <woods@weird.com>