The nonblonde store is organized in blocks. The blocks are the disk images of the b-tree nodes and of the large keys and data. They have a variable size. Both their size and the file offset at which they occur are a multiple of 1K.
The store is meant to keep the database in an intended state, reflecting a transaction closing. It is also meant to require no recovery procedure and no temporary data storage, such as logs files, etc. Normal operation, application crashes, etc, should see no data corruption. Power failures, operating system and hardware failures, everything that interferes with how the data is written by the OS on disk, may reveal broken databases.
In order to have the database in working order at any one time, the nonblonde store does not overwrite live data. Everytime a block is modified and needs to be rewritten, a new copy is made, at a different location.
For their possibly frequent relocation, the store blocks are known by block ids and not by file offsets. Block referring other blocks (such as internal b-tree nodes referring external nodes, external nodes referring large key and data pages, etc) record the referred nodes by their ids. A page map (or block map) associates page (block) ids with actual file offsets.
Transactions see a series of changes made to the database, resulting in a number of b-tree nodes and key/data pages getting modified. The latter are all written on free space in the store when the transaction is closed, at which time both the pre- and post-transaction data coexists. The addition of the new block copies is reflected by the page map as a new entry. The single entry, which at subsequent database reopenings is parsed either whole or not at all, records the relocation file offsets of the changed blocks.
The page map is written sequentially, with new entries added at the end.
Several past transactions are meant to be preserved (though currently a database closing flushes the transaction history). Those that are may be rolled back by removing their recording in the page map (no C interface currently available for this). For an instance, removing the last byte from the page map file will see the last transaction dumped on a subsequent database reopening (the database would be closed during such a roll back operation).
As the page map only grows and never shrinks by itself, it needs to be compacted regularly.