LStore —
the distributed file system
that anchors the solution set.
A fault-tolerant, configurable-per-dataset distributed file system in production at Vanderbilt's ACCRE — covered here in the depth that the platform deserves and that no other public source provides.
Why we cover LStore comprehensively.
LStore is a sophisticated distributed file system with architectural ideas that don't appear in commodity storage products. It deserves a thorough public reference — and at present, no such reference exists outside its own developer documentation.
LStore is open source and developed in the open. ACCRE is its home and primary engineering center, and the public repository is open to contribution from other institutions — Unique Checksum among them.
This section is that reference. The pages listed alongside cover LStore from the foundations of the storage abstraction up through engagement and lifecycle. Each page is written for a substantive technical reader; together they describe the platform as a whole, not as a single deployment or a single integration.
By adopting an LStore-based architecture, ACCRE expects to reduce its average cost of storage by 48 percent while providing faster, more flexible data access to the Vanderbilt research community.
Paraphrased from the public Hammerspace announcement, 20 November 2025.
Read the announcement →
What LStore is.
LStore is a fault-tolerant distributed file system whose architecture is best understood through two complementary views — one describing how a request flows through the software stack, the other describing what is actually deployed and where it runs.
Five composable layers
At the bottom, the Data Service layer exposes whatever storage a depot has as a network-addressable byte-array abstraction; the current implementation is the Internet Backplane Protocol, and the plugin is named ds_ibp for data service, IBP. Above it, Layer 2 splits into two paths. The Exnode side describes each file's storage composition — segment hierarchy, encoding parameters, placement query, integrity options — and reaches down through the data path to the Data Service. The Object Service side is a self-contained container for arbitrary attributes; the exnode lives there as one attribute among many, and the Object Service itself performs no processing. Above the split, LIO — Logistical I/O — is the coordinator, deciding for each operation which path to take, and hosting the Resource Service as an internal component used on the data-path side. Above LIO, the File System layer presents POSIX semantics — open, read, write, stat — to the application through LIO_fuse, the command-line tools, or programmatic bindings.
Each layer has multiple plugin implementations; the working configuration is assembled per deployment, and within a deployment, every file can be configured independently. The result is a storage platform in which encoding, placement, integrity verification, and lifecycle behavior are per-dataset policy rather than appliance defaults.
Three deployment components
Read as a deployment, LStore is three things. The IBP Server Depots are the physical or virtual storage nodes that hold the actual data. The LStore Metadata Server — the LServer — holds the metadata services that make the filesystem coherent: the Object Service for filesystem semantics, the Resource Service for placement queries, the Authentication service, and the message-queue broker that connects clients to all of them. The LStore Clients are whatever machines attach to an LServer and run applications against it.
The architectural property worth surfacing at this level is the separation between the data path and the metadata path. Clients talk to depots directly via IBP for the actual reading and writing of bytes; clients talk to the LServer separately, over a message-queue transport, for the metadata exchange. The data path does not pass through the metadata server. This is what allows LStore's throughput to scale with the number of depots in a deployment rather than against any single server's capacity.
Where LStore sits in the tiered architecture.
In a complete deployment, LStore occupies the capacity tier — the multi-petabyte, fault-tolerant core that holds the bulk of an organization's research, AI, or large-data working set. Higher-performance tiers feed it from above; archive and tape tiers extend it below. The diagram is a reference shape; specific deployments scale individual tiers up or down based on workload.
Figure 1 · Reference architecture — LStore as the capacity tier within a complete deployment
Architecture, end to end.
The diagram above describes data placement across tiers. A complete account of an AI-scale or HPC-scale deployment also includes the physical layer underneath it — what gets built, where it gets deployed, how it is powered and cooled, and how the resulting capacity is orchestrated against workload demand.
That physical layer has two distinct dimensions, and serious deployments have to solve both. The first is delivery: engineering, specifying, sourcing, building, integrating, and standing up the physical infrastructure — at scale, in conventional data centers and research computing facilities, or in containerized form for deployments that need to land where conventional facilities don't reach. The second is orchestration: matching workloads to physical resources continuously, aligning placement with power profile and lifecycle stage, and making the energy and capacity decisions that keep large infrastructure efficient at scale.
At scale, every dimension either gets optimized continuously or becomes a constraint on what the infrastructure can do. Storage policy, physical-layer build, and physical-resource orchestration are three faces of the same problem — and the firms that treat them as separate concerns leave efficiency on the table.
Unique Checksum speaks to all three. The LStore pages that follow focus on the data-policy half, where the per-dataset configurability of LStore creates direct opportunities to align storage decisions with physical-resource realities — drive class, depot location, power profile, deployment form factor, and lifecycle stage. Where physical-layer delivery and physical-resource orchestration enter the conversation explicitly, they appear in Operations & Lifecycle.
What's in this section.
Each page is focused. Read in order for a complete picture, or jump directly to the dimension of LStore you need:
Architecture The Exnode Resource Service LServer Reliability Operations Engagement Roadmap Provenance
Unique Checksum specifies, sources, and provides access. The client operates.
We enable. We do not compete downstream.