ron@manta.UUCP (Ron Broersma) (09/30/87)
We have an application which uses ndbm and recently grew to where key/content
pairs were larger than 1K. This caused dbm_store to return an error. But
the man page says this shouldn't happen until you hit 4K.
So, my questions are:
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.
2. Are there any problems with changing this to 4096 other than it being
incompatible with old databases?
3. Wouldn't it make more sense to set DBLKSIZ to to whatever the filesystem
blocksize is (st_blksize).
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.
--Ron
ron@nosc.mil (ARPA)
sdcsvax!nosc!ron (UUCP)chris@mimsy.UUCP (10/03/87)
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