Orleans.Lattice.Storage.File
This page documents Orleans.Lattice.Storage.File 9.9.0, in the documentation for Orleans.Lattice 9.9.0 (release line 9.9), built 2026-10-04. It is also published as markdown, with every table and list, at README.md, and llms.txt lists every page.Durable, cloud-free local disk WAL provider for Orleans.Lattice. It plugs into the public IWalStorageProvider seam so a single-cluster deployment can persist its commit log to a mounted directory - crash-safe across silo restarts - without an external storage account.
What is it?
Orleans.Lattice.Storage.File is the optional on-disk WAL backend for the core lattice:
- Durable WAL storage.
FileWalStorageProviderstores each WAL partition of each tree as a segmented, append-only file on the local filesystem and implements the publicIWalStorageProvidercontract. - All-or-nothing batch append. Each batch is framed as a run of data records sealed by a single commit trailer and made durable with one write plus fsync; a crash before the trailer is durable rolls the whole batch back on recovery.
- Restart recovery. Activation-time reconciliation rolls every committed batch forward, discards a torn tail, and reclaims trimmed space, so after a crash the log ends cleanly at its last committed batch; an honest offset gap left by a failed append is preserved, never renumbered.
- Drop-in registration.
AddFileWalStoragedisplaces the in-memory WAL backend installed by core lattice registration, and wires the durable-WAL garbage-collection stack alongside it.
As a WAL store it matches the observable durability guarantees of the Azure Table Storage provider without any cloud dependency. Tree state - each leaf's state row and its snapshots - still lives in the grain storage provider AddLattice registers, so a durable deployment pairs it with a durable grain storage provider, which must enforce ETags on write (see The grain storage provider must enforce ETags); that pairing makes it the enabler for a single-container, "codebase memory in a box" deployment (see the RepoContext MCP package and its container sample, which uses Orleans ADO.NET grain storage over a single SQLite file).
Core WAL semantics, the provider seam, and placement are covered in WAL Storage Providers.
Core Properties
- Per-shard ordering. Offsets are stored verbatim and read back in ascending order within each
(tree, shard)stream. - Batch atomicity. A successful append is visible as a complete batch; a torn or uncommitted trailing batch leaves no visible partial state after recovery.
- Crash recoverability. Interrupted appends are reconciled before normal reads and writes rely on the stored tail.
- Self-compacting. Trimmed payload bytes are physically reclaimed by rewriting a shard's segment file once enough dead space accumulates.
- Published to NuGet as
Orleans.Lattice.Storage.File, released underlattice.storage.file-v<X.Y.Z>tags.
Public surface
| Type or member | Role |
|---|---|
FileWalStorageProvider |
Public IWalStorageProvider implementation (also IDisposable) that stores one wal.log per (tree, shard) stream under FileWalStorageOptions.RootDirectory. Its public constructor, FileWalStorageProvider(IOptions<FileWalStorageOptions>, Serializer<WalRecord>), builds a provider without the routing reader, so its filtered replay reads decode every record they examine; AddFileWalStorage is the registration that supplies one. |
FileWalStorageOptions |
Public options type for the root directory, flush policy, compaction thresholds, and read-page byte ceiling, with public Default* constants for the compaction and read-page defaults. |
LatticeFileServiceCollectionExtensions.AddFileWalStorage |
Registration extension that installs the file WAL provider, its options validator, and the durable-WAL garbage-collection wiring on an ISiloBuilder. |
Quick Start
Install the package and register it on the silo that owns the WAL:
dotnet add package Orleans.Lattice.Storage.File
using Orleans.Lattice.Storage.File;
siloBuilder.AddFileWalStorage(options =>
{
options.RootDirectory = "/data/wal";
});
Register it alongside AddLattice(...) on the silo that owns the WAL. The registration order does not matter: AddFileWalStorage displaces the in-memory baseline whether it runs before or after AddLattice.
Reference
- Configuration - every
FileWalStorageOptionsknob, default, and validation rule. - Architecture - the on-disk layout, the append/commit framing, the durability contract, compaction, and recovery behaviour.
Related package docs:
- Core WAL Storage Providers - the core provider seam, in-memory default, and WAL placement.
- Core WAL - single-cluster WAL commit and replay semantics.
- Azure Table WAL provider - the cloud-backed alternative with the same durability contract.