.spec · wire-format · §4
Filesystem metadata.
Layer 2 — the POSIX-ish metadata: inodes, directory tree, xattrs, slice → drop maps. The directory tree is a deterministic Merkle B-tree: every node content-addressed, structural sharing built in for deltas.
A deterministic Merkle B-tree. Each node is content-addressed by BLAKE3 of its sorted children. Delta that touches one leaf writes only O(log N) new nodes along the changed path.
§4.1 — Inode
An inode represents a filesystem object. Every entry in the directory tree references an inode. Fields (all exact-width):
| Field | Type | Notes |
|---|---|---|
number | u64 LE | inode number, unique within image |
mode | u32 LE | POSIX mode bits (file type + permissions) |
uid, gid | u32 LE each | owner user / group IDs |
mtime_ns, ctime_ns, atime_ns | u64 LE each | times in ns since Unix epoch |
nlink | u32 LE | hard-link count |
xattrs | [XAttr] | §4.4 extended attributes |
content_handle | ContentHandle | §4.3 — slice map, redirect, or special |
§4.2 — Directory representation
A directory inode’s content_handle is a Merkle B-tree node. The directory
tree is a deterministic Merkle B-tree (not Prolly Tree proper, which uses
content-defined chunking for boundaries — conflicts with §1.4 determinism). Split
decisions are spec-pinned: split when a node has N entries.
Why a Merkle B-tree?
- Content-addressed structural sharing. Delta touching one file writes O(log N) new nodes — unchanged subtrees are referenced, not copied.
- Multihash-compatible. Node hashes are BLAKE3-256; display form
b3:<base32>maps to IPFS/IPLD CIDs directly. - Stable boundaries across versions. Same content = same hash = same node, regardless of where in the tree the change happened.
§4.3 — Content handles and slice maps
A regular file inode’s content_handle is a slice map. For files above the
inline-data threshold, inline_data is absent and slices
contains the file’s chunks in byte order. A slice_id resolves to a
(byte_range_in_slice, DropId) mapping; readers follow the chain to fetch
drops.
Symlink inodes carry a redirect field with the target path. Special inodes
(block, char, fifo, socket) carry the device number or pipe identifier.
§4.4 — xattrs
Extended attributes are (namespace, key, value) triples. Namespaces:
0x00— user0x01— trusted0x02— system0x03— security
Readers MUST enforce the namespace policy of the host OS (e.g., security.SELinux requires privilege).
§4.5 — atime omission
Some images omit atime to save space. When omitted, readers MUST treat
atime reads as returning mtime_ns and MUST NOT report the
omission as an error.
§4.6 — Per-class records (Seine)
For each drop in the image, the metadata records the Seine classification (§13) so deepening (§8.4) is reproducible: same drop head bytes + same classifier registry ⇒ same class.