Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP Path: utzoo!utgpu!water!watmath!clyde!rutgers!ll-xn!husc6!seismo!mimsy!chris From: chris@mimsy.UUCP Newsgroups: comp.bugs.4bsd Subject: Re: 4.3BSD ndbm(3) key/content length restriction Message-ID: <6807@mimsy.UUCP> Date: Wed, 27-May-87 21:09:16 EDT Article-I.D.: mimsy.6807 Posted: Wed May 27 21:09:16 1987 Date-Received: Fri, 29-May-87 01:31:05 EDT References: <1739@megaron.arizona.edu> <3231@sdcsvax.UCSD.EDU> Organization: U of Maryland, Dept. of Computer Science, Coll. Pk., MD 20742 Lines: 40 >In article <1739@megaron.arizona.edu> whm@arizona.edu (Bill Mitchell) writes: >>... it appears that the actual [key+content length restriction] is >>1024 [bytes], rising from #define PBLKSIZ 1024 in . In article <3231@sdcsvax.UCSD.EDU> allyn@sdcsvax.UCSD.EDU (Allyn Fratkin) writes: >It makes little sense (to me) to have DBLKSIZE be so large since most >databases don't get that big. ... isn't the .dir file basically a >bitmap (used in the hash calculation) of the available file pages? More precisely, it is a sort of binary tree describing which pages have been split. It takes 2 ** ceil(log (n+1)) - 1 2 bits to describe an n-page database. Our old hashed host files are 2020352 bytes, or 1973 pages, requiring 2048 bits. The 4096 DBLKSIZ means that one can describe a 32767 page, or ~33Mbyte, database without ever having to swap bitmap blocks. In practise, it takes fewer bits, as only ones are stored. One could have a database grow to 64MB before a second bitmap block was required. Increasing PBLKSIZ means that larger databases need fewer bits (since each bit describes a larger `page'), but increases the memory-to-memory copying overhead involved in adding and deleting items. On a 4K-block file system, it will improve I/O bandwidth. In short, it would probably be a win to change DBLKSIZ TO 1024 and PBLKSIZ to 4096. Alas, all old databases would have to be reconstructed. (Mdbm does not suffer from this problem: the data and map block sizes are set at database creation, and are stored in the database itself.) Incidentally, the actual key+content length restriction is PBLKSIZ - 3 * sizeof (short), or 1018 bytes in 4.3BSD. -- In-Real-Life: Chris Torek, Univ of MD Comp Sci Dept (+1 301 454 7690) Domain: chris@mimsy.umd.edu Path: seismo!mimsy!chris