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.
DataObjectHandle is a typed handle for file-like objects that store data in the default data
attribute. In addition to traditional files, this means things like the journal, superblocks,
and layer files.
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.
Whether this particular logical file range is in overwrite or CoW mode. Overwrite mode ranges
have overwrite extents already allocated, and should use multi_overwrite. CoW mode ranges
should use multi_write, and might or might not have extents in the region already.
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.