Type Alias Mutation 

pub type Mutation = MutationV62;

The journal consists of these records which will be replayed at mount time. Within a transaction, these are stored as a set which allows some mutations to be deduplicated and found (and we require custom comparison functions below). For example, we need to be able to find object size changes.

Aliased Type

pub enum Mutation {
    ObjectStore(ObjectStoreMutationV62),
    EncryptedObjectStore(Box<[u8]>),
    Allocator(AllocatorMutationV32),
    BeginFlush,
    EndFlush(u64),
    DeleteVolume,
    UpdateMutationsKey(UpdateMutationsKeyV49),
    CreateInternalDir(u64),
    UpdateBorrowed(u64),
}

Variants

ObjectStore(ObjectStoreMutationV62)

EncryptedObjectStore(Box<[u8]>)

Allocator(AllocatorMutationV32)

BeginFlush

Indicates the beginning of a flush. This would typically involve sealing a tree.

EndFlush(u64)

Indicates the end of a flush. This would typically involve replacing the immutable layers with compacted ones. The u64 records the child store’s new flushed layer borrowing (store_borrowed, or 0 for full compactions and system objects).

DeleteVolume

Volume has been deleted. Requires we remove it from the set of managed ObjectStore.

UpdateMutationsKey(UpdateMutationsKeyV49)

CreateInternalDir(u64)

UpdateBorrowed(u64)

Legacy < V61 mutation only produced in memory when migrating MutationV59 during journal replay (#[serde(skip)] prevents serializing or deserializing this variant in V61+ streams). This can be removed once all < V61 versions are removed; it must remain the last variant so that the serialized variant tags of the preceding variants do not change when it is removed.

Implementations

impl Mutation

pub fn insert_object(key: ObjectKey, value: ObjectValue) -> Self

pub fn replace_or_insert_object(key: ObjectKey, value: ObjectValue) -> Self

pub fn merge_object(key: ObjectKey, value: ObjectValue) -> Self

pub fn update_mutations_key(key: FxfsKey) -> Self

pub fn counts_towards_object_journal_usage(&self) -> bool

Returns true if this mutation’s serialized journal bytes should be accounted against the target object’s per-store journal usage (J_S) rather than system journal usage (J_sys).

Lifecycle control records (BeginFlush, EndFlush, and DeleteVolume) are not written into an object store’s layer files, and BeginFlush/EndFlush are committed in Borrowed transactions where apply_mutation transitions journal_checkpoints and store_borrowed before post-transaction usage accounting runs. Accounting their bytes in J_sys ensures they do not re-dirty journal_checkpoints or add post-flush borrowed debt to store_borrowed.