It is imperative that fakefs never allow itself to run completely out of disk space.
Berkeley DB requires disk space for logging all modifications to the database--including deletions. In particular, deleting an object requires transaction log space proportional to the size of the object being deleted, and doesn't release any space from the database file to the host OS.
If we want to delete a 10MB object we need at least 10MB of free space to log the transaction. Ouch!
If we later insert an 11MB object, we require 12MB of free space: 11MB for the transaction log, and 1MB of new free space for the object (the other 10MB uses previously freed space). Fortunately Berkeley DB gets this right.
Simple transaction-protected reads do not seem to consume log space, at least in single-reader cases.
We don't want to store large objects inside Berkeley DB lest we be unable to find sufficient space to remove them afterwards. Also, Berkeley DB refuses to mmap() large databases by default (and can't mmap() a database larger than the host CPU address space in any case due to API limitations), which means that for all practical purposes, any data retrieved from the database is copied into anonymous virtual memory (i.e. RAM + swap). Assuming:
it follows that we want a maximum value data size of 25% of system RAM, probably much smaller. For a machine with 768MB of RAM running 5 fakefs processes, this works out to about 38MB. For a machine with 96MB of RAM, this works out to 4MB.
Note that we can tell Berkeley DB to write data directly to an mmap()ed file, which saves us the RAM of one copy of the data. This is usually what we want to do with the data anyway.