Provider / file-backed relational state
ValidatedSQLite
SQLite is the local durable option when the application owns database files and can apply the repository's locking and journal-mode rules. Metadata and blocks may use separate database files or be paired with another provider.
SqliteMetadataStore stores the namespace JSON, revision, writer owner/fence/expiry, volume identity, and versioning tables inmount_rs_metadata plus the version tables.
SqliteBlockStore stores immutable bytes inmount_rs_blocks(id, bytes). It can live in a second SQLite database so metadata publication and block storage remain separate.
Storage anatomy
Follow one file through both planes.
A mount-rs namespace stores names, attributes, directory entries, layouts, and block references. The bytes stay in the independent block plane. The example below is illustrative; the provider-specific schema, keys, and prefixes are the inspectable contract.
inode 42 · size 8,192NodeMetadata → NodeData::File(FileLayout)BlockId → raw bytesNamespace {
nodes[42] = NodeMetadata {
stats: { ino: 42, size: 8192, mode: regular },
data: File(FileLayout {
chunker: { algorithm: "fixed-size", version: 1, chunk_size: 4096 },
extents: [
{ file_offset: 0, block: "b012...", block_offset: 0, length: 4096 },
{ file_offset: 4096, block: "bfed...", block_offset: 0, length: 4096 }
]
})
}
}
BlockId "b012..." -> [4 KiB raw bytes]
BlockId "bfed..." -> [4 KiB raw bytes]Relational storage
SQLite file(s) schema
The current split-store schema is normalized into six active tables. Metadata and blocks can be separate SQLite files; the table names stay the same.
mount_rs_metadata
One current namespace snapshot plus the writer lease and revision CAS state.
| Column | Type | Stored meaning |
|---|---|---|
id | INTEGER | fixed singleton key; CHECK(id=1) |
volume_id | TEXT | stable volume identity; added by migration |
revision | INTEGER | monotonic namespace revision |
namespace | TEXT NULL | serialized Namespace: nodes, attributes, layouts, block IDs |
owner | TEXT NULL | current writer owner |
fence | INTEGER | monotonic fencing token |
expires | INTEGER | provider-clock lease expiry |
mount_rs_blocks
Immutable byte blocks referenced by Namespace FileLayout extents.
| Column | Type | Stored meaning |
|---|---|---|
id | TEXT | opaque BlockId |
bytes | BLOB | raw block bytes; never a path or directory record |
mount_rs_schema_versions
Migration marker for the versioning schema.
| Column | Type | Stored meaning |
|---|---|---|
schema_name | TEXT | schema identifier |
schema_version | INTEGER | applied schema version |
mount_rs_version_state
One row tracking the version head and the next sequence/fence values.
| Column | Type | Stored meaning |
|---|---|---|
id | INTEGER | fixed singleton key; CHECK(id=1) |
volume_id | TEXT | volume this version graph belongs to |
head_id | TEXT NULL | current published version |
next_sequence | INTEGER | next version sequence |
next_read_fence | INTEGER | next reader fence |
mount_rs_versions
Published namespace snapshots and their parent/fork lineage.
| Column | Type | Stored meaning |
|---|---|---|
id | TEXT | version identifier |
volume_id | TEXT | owning volume |
sequence | INTEGER | monotonic version sequence |
parent_id | TEXT NULL | previous version |
restored_from | TEXT NULL | restore source, if any |
forked_from | TEXT NULL | fork source, if any |
namespace | TEXT | serialized namespace for this version |
block_store_id | TEXT | block-plane identity |
kind | TEXT | publication kind |
created_at_ms | INTEGER | creation timestamp |
durable | INTEGER | durability assertion; 0 or 1 |
operation_id | TEXT | idempotency key; UNIQUE |
mount_rs_version_pins
Reader views that pin a version while it is being consumed.
| Column | Type | Stored meaning |
|---|---|---|
view_id | TEXT | reader view identifier |
volume_id | TEXT | owning volume |
version_id | TEXT | pinned version |
owner | TEXT | reader owner |
fence | INTEGER | reader fence |
expires | INTEGER | pin expiry |
Compatibility boundary
Legacy snapshot schema
These tables belong to the older snapshot state-store API. They should not be mistaken for the active metadata/block composition.
mount_rs_state
Legacy SqliteFs snapshot table; not part of the split MetadataStore/BlockStore schema above.
| Column | Type | Stored meaning |
|---|---|---|
id | INTEGER | fixed singleton key; CHECK(id=1) |
revision | INTEGER | snapshot revision |
snapshot | BLOB | serialized persisted filesystem snapshot |
Only expect this table when the legacy SqliteFs state-store API is selected.
SELECT name, sql
FROM sqlite_master
WHERE type = 'table' AND name LIKE 'mount_rs_%'
ORDER BY name;
PRAGMA table_info(mount_rs_metadata);
PRAGMA table_info(mount_rs_blocks);
PRAGMA table_info(mount_rs_versions);File-backed provider and Linux FUSE hosting have scoped evidence; not universal SQLite safety. Local provider tests and revision-matched Linux FUSE checks cover file reopen, leases, SQLite transactions, and selected recovery/fault paths. The repository still tracks hosted, Windows, and broader transport acceptance separately.
Layout and chunking
ChunkedFs records fixed-size chunk configuration in the namespace/file layout. A block row contains the opaque block ID and a BLOB; SQLite does not reinterpret the bytes as files or pages owned by the mount layer.
Durability and consistency
File-backed databases enable the provider's durable flag and use SQLite's synchronous=FULL setup plus provider-clock lease and revision checks. In-memory SQLite is volatile. SQLite used as a provider is different from hosting a separate SQLite database inside a native mount.
Across every split-store composition, new blocks are flushed before metadata references are published. A provider acknowledgement is not automatically a power-loss or distributed-locking guarantee.
Inspect metadata and blocks with sqlite3
sqlite3 metadata.sqlite <<'SQL'
SELECT id, revision, length(namespace) AS namespace_bytes
FROM mount_rs_metadata;
SELECT id, sequence, durable FROM mount_rs_versions
ORDER BY sequence DESC LIMIT 10;
SQL
sqlite3 blocks.sqlite 'SELECT id, length(bytes) AS block_bytes FROM mount_rs_blocks LIMIT 20;'Credentials, cleanup, and safe operations
Close all filesystem handles before copying or deleting database files. Remove only databases owned by the volume; never delete block rows that a live metadata revision may still reference. SQLite has no network credentials in this provider path.
Current limits
The provider's file durability does not prove safe SQLite hosting over every transport. The verified Linux FUSE matrix and macOS single-host NFS DELETE-journal path do not establish universal WAL, power-loss, distributed-locking, or cross-platform guarantees.
Sources: SQLite provider source · SQLite reliability matrix