Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: utzoo!utgpu!water!watmath!clyde!rutgers!husc6!cmcl2!brl-adm!umd5!mimsy!chris
From: chris@mimsy.UUCP
Newsgroups: comp.unix.wizards
Subject: Re: ndbm(3) question.  4.3 BSD.
Message-ID: <8897@mimsy.UUCP>
Date: Sat, 3-Oct-87 12:50:01 EDT
Article-I.D.: mimsy.8897
Posted: Sat Oct  3 12:50:01 1987
Date-Received: Sun, 4-Oct-87 06:53:45 EDT
References: <256@manta.UUCP>
Organization: U of Maryland, Dept. of Computer Science, Coll. Pk., MD 20742
Lines: 39

In article <256@manta.UUCP> ron@manta.UUCP (Ron Broersma) writes:
>1.  Why does the man page say that the internal block size is 4096 when
>    ndbm.h has PBLKSIZ set to 1024.  DBLKSIZ is already 4096.

A bug.  Whether it is in the manual or in the source is a matter of
opinion.

>2.  Are there any problems with changing this to 4096 other than it being
>    incompatible with old databases?

Larger PBLKSIZes also mean that more items are stored in each .pag
block; this in turn means that there will be fewer bits set in the
.dir file, and that fetching or storing an item will take longer
on average.

>3.  Wouldn't it make more sense to set DBLKSIZ to to whatever the filesystem
>    blocksize is (st_blksize).

No; if this were done, and you rebuilt the file system with a different
block size (as, e.g., we did with /u [user home directories] when it
got full as an 8K/1K file system: as a 4K/512 fs it suddenly had several
megabytes free), database files would suddenly become hard to use.

>We did try to run it with PBLKSIZ set to 4096.  It seemed to work fine.
>The other observation was that the .dir file was much smaller.

This is why in my `mdbm' variant of extensible-hashing-database-libraries,
I allow the program creating a database to specify both the bitmap
block size and the item buffer block size.  The bad news:  I have
stopped distributing mdbm (lawyers again).  The good news:  It may
well be in the next BSD (assuming there is a next BSD, disclaimer
etc. ad nauseam).  mdbm makes a different set of tradeoffs so as
to handle multiple keys to single objects more space-efficiently.

(I suppose if someone were desperate, and sent me a copy of a 4.3BSD
source license, I could give out sources.)
-- 
In-Real-Life: Chris Torek, Univ of MD Comp Sci Dept (+1 301 454 7690)
Domain:	chris@mimsy.umd.edu	Path:	uunet!mimsy!chris