Module super_block

We currently store two of these super-blocks (A/B) starting at offset 0 and 512kB.

Immediately following the serialized SuperBlockHeader structure below is a stream of serialized operations that are replayed into the root parent ObjectStore. Note that the root parent object store exists entirely in RAM until serialized back into the super-block.

Super-blocks are updated alternately with a monotonically increasing generation number. At mount time, the super-block used is the valid SuperBlock with the highest generation number.

Note the asymmetry here regarding load/save:

• We load a superblock from a Device/SuperBlockInstance and return a (SuperBlockHeader, ObjectStore) pair. The ObjectStore is populated directly from device.
• We save a superblock from a (SuperBlockHeader, Vec) pair to a WriteObjectHandle.

This asymmetry is required for consistency. The Vec is produced by scanning the root_parent_store. This is the responsibility of the journal code, which must hold a lock to avoid concurrent updates. However, this lock must NOT be held when saving the superblock as additional extents may need to be allocated as part of the save process.

Structs

RecordReader

SuperBlockHeaderV32

SuperBlockManager

This encapsulates the A/B alternating super-block logic. All super-block load/save operations should be via the methods on this type.

Enums

SuperBlockInstance

An enum representing one of our super-block instances.

SuperBlockRecordV40

SuperBlockRecordV41

SuperBlockRecordV43

Constants

SUPER_BLOCK_CHUNK_SIZE

The superblock is extended in units of SUPER_BLOCK_CHUNK_SIZE as required.

Functions

compact_root_parent

Type Aliases

SuperBlockHeader

SuperBlockRecord