pub use caching_object_handle::CachingObjectHandle;
pub use directory::Directory;
pub use allocator::AllocatorInfo;
pub use allocator::AllocatorKey;
pub use allocator::AllocatorValue;
pub use journal::JournalRecord;
pub use journal::JournalRecordV20;
pub use journal::JournalRecordV25;
pub use journal::JournalRecordV29;
pub use journal::JournalRecordV30;
pub use journal::JournalRecordV31;
pub use journal::JournalRecordV32;
pub use journal::SuperBlockHeader;
pub use journal::SuperBlockRecord;
pub use journal::SuperBlockRecordV25;
pub use journal::SuperBlockRecordV29;
pub use journal::SuperBlockRecordV30;
pub use journal::SuperBlockRecordV31;
pub use journal::SuperBlockRecordV5;
pub use transaction::Mutation;
- 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.
- Id and descriptor for a child entry.
- 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.
- Like object_handle::Writer, but allows custom transaction options to be set, and makes every write go directly to the handle in a transaction.
- ExtentKey is a child of ObjectKey for Object attributes that have attached extents (at time of writing this was only the used for file contents).
- TODO(b/308870667): Potentially revise FsverityMetadata with stricter types and storage optimizations.
- Object-level attributes. Note that these are not the same as “attributes” in the ObjectValue::Attribute sense, which refers to an arbitrary data payload associated with an object. This naming collision is unfortunate.
- ObjectKey is a key in the object store.
- 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.
- This consists of POSIX attributes that are not used in Fxfs but it may be meaningful to some clients to have the ability to to set and retrieve these values.
- 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.
- UNIX epoch based timestamp in the UTC timezone.
- ExtentValue is the payload for an extent in the object store, which describes where the extent is physically located.
- ObjectDescriptor is the set of possible records in the object store.
- ObjectValue is the value of an item in the object store. Note that the tree stores deltas on objects, so these values describe deltas. Unless specified otherwise, a value indicates an insert/replace mutation.
- For specifying what property of the project is being addressed.
- 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.
- Argument to the trim_some method.
- Result of the trim_some method.
- For Blobs in Fxfs, we store the merkle tree at a well-known attribute. TODO(fxbug.dev/122125): Is this the best place to store the merkle tree? What about inline with data?
- The common case for extents which cover the data payload of some object.
- 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.
- For fsverity files in Fxfs, we store the merkle tree of the verified file at a well-known attribute.
- DataObjectHandle stores an owner that must implement this trait, which allows the handle to get back to an ObjectStore.
- Loads store info.