||This article needs more links to other articles to help integrate it into the encyclopedia. (November 2013)|
|This article needs additional citations for verification. (November 2013)|
ndbm (standing for New Database Manager) is a Berkeley produced version from 1986 of the AT&T dbm database.
ndbm stores arbitrary data by use of a single key in fixed-size buckets.
The sum of the sizes of a key/content pair must not exceed the internal block size (normally between 512 and 4096 bytes). Moreover all key/content pairs that hash together must fit on a single block.
When storing an entry, dbm_store() stores the data in the block that corresponds to the hash of the key. If two or more keys hashes to the same value, all data for those keys must be stored in the same data block. dbm_store() is supposed to return an error in the event that a disk block fills up, but there are situations where it doesn't, and you could just end up quietly delete another entry.
Since you do not know which keys hash together, you may not depend on them hashing to different buckets. If you are unlucky, all your keys could hash to the same hash value and therefore all your data and some unknown internal metadata must fit in one bucket, which is one block (normally 512-4096 bytes).
This means that the entire database is only guaranteed to be fully stored and retrievable if the entire dataset including some internal metadata fits in one disk block. If you store more data than that, some data may in some situations just quietly disappear.
Obviously, because of this, if you are interested in being able to retrieve stored data, ndbm should not be used, and almost any other storage format is better than ndbm.
The problem is very seldom mentioned in the documentation. One of the few places is a note in the Solaris ndbm(3C) man page.
Still, for historical reasons, ndbm is delivered with several operating systems and used by several programs and systems out there.
- Oracle Solaris. "Solaris ndbm(3C) man page, under notes".