Ndbm

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.

Problems

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.

Discussion

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.^[1]

Still, for historical reasons, ndbm is delivered with several operating systems and used by several programs and systems out there.

References