Expand description
The journal is implemented as an ever extending file which contains variable length records that describe mutations to be applied to various objects. The journal file consists of blocks, with a checksum at the end of each block, but otherwise it can be considered a continuous stream.
The checksum is seeded with the checksum from the previous block. To free space in the journal, records are replaced with sparse extents when it is known they are no longer needed to mount.
At mount time, the journal is replayed: the mutations are applied into memory. Eventually, a checksum failure will indicate no more records exist to be replayed, at which point the mount can continue and the journal will be extended from that point with further mutations as required.
Modules§
- super_
block - We currently store two of these super-blocks (A/B) starting at offset 0 and 512kB.
Structs§
- Journal
- The journal records a stream of mutations that are to be applied to other objects. At mount time, these records can be replayed into memory. It provides a way to quickly persist changes without having to make a large number of writes; they can be deferred to a later time (e.g. when a sufficient number have been queued). It also provides support for transactions, the ability to have mutations that are to be applied atomically together.
- Journal
Checkpoint V32 - Journal
Options - Journaled
Checksums - Journaled
Transaction - Writer
- Wrapper to allow records to be written to the journal.
Enums§
Constants§
Traits§
- Journal
Handle - Handles for journal-like objects have some additional functionality to manage their extents, since during replay we need to add extents as we find them.