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.
An object store supports a file like interface for objects. Objects are keyed by a 64 bit
identifier. And object store has to be backed by a parent object store (which stores metadata
for the object store). The top-level object store (a.k.a. the root parent object store) is
in-memory only.
StoreObjectHandle is the lowest-level, untyped handle to an object with the id [object_id] in
a particular store, [owner]. It provides functionality shared across all objects, such as
reading and writing attributes and managing encryption keys.
The mode of operation when setting extended attributes. This is the same as the fidl definition
but is replicated here so we don’t have fuchsia.io structures in the api, so this can be used
on host.
For Blobs in Fxfs, we store the merkle tree at a well-known attribute.
TODO(https://fxbug.dev/42073113): Is this the best place to store the merkle tree? What about inline with
data?
The range of fxfs attribute ids which are reserved for extended attribute values. Whenever a
new attribute is needed, the first unused id will be chosen from this range. It’s technically
safe to change these values, but it has potential consequences - they are only used during id
selection, so any existing extended attributes keep their ids, which means any past or present
selected range here could potentially have used attributes unless they are explicitly migrated,
which isn’t currently done.
StoreInfo stores information about the object store. This is stored within the parent object
store, and is used, for example, to get the persistent layer objects.