Operations & lifecycle.
Storage at research-computing scale is a flow, not a fixture. Data enters on one tier, moves to another as access patterns evolve, and ends on a third when retention policy says so. In LStore, that flow is not a separate management system bolted on top of the storage platform; it is the natural consequence of the per-file metadata model that runs through the rest of the architecture. This page describes how the lifecycle works in production at ACCRE — the tiered orchestration with Hammerspace, the policy-driven migration, the depot operations that sustain the persistent tier, and the archive integration that completes the cycle.
A file’s life is the same file all the way through.
A storage platform that treats lifecycle as a separate concern — a tiering engine, an archive system, a migration tool, each operating against the storage from outside — ends up with the migration boundaries showing in the application. Files move between systems and acquire different identities. LStore takes a different approach. The lifecycle is a property of the file’s exnode, evolves with it, and never requires the file to become a different file. This is what the architecture pages mean when they describe lifecycle as per-dataset policy.
The mechanism is the same one that makes encoding, placement, and integrity options per-file: the exnode is a document that describes a file’s storage composition, and that composition can change. Segments can be added, removed, or replaced. A file’s segments can point at high-performance storage today and at long-tail capacity tomorrow, with the exnode rewritten as the migration completes. From above the exnode, in the application’s view, nothing has changed — the file has the same name, the same permissions, the same path. From below the exnode, the file’s bytes have moved to a different set of allocations on a different set of depots, and the lifecycle has done its work invisibly.
This is the framing that connects everything on this page. The architecture page establishes that LStore is a five-layer system with the exnode at the policy layer. The exnode page establishes that segments compose a file’s storage and can be modified through the standard tooling. The Resource Service page establishes that placement is queryable policy rather than static configuration. The lifecycle layer is what activates all three: it is the set of policies that move files between resources over time, expressed as exnode modifications and segment migrations, operating against the resource registry to decide where data should land at each stage.
At ACCRE, the orchestrator that runs this lifecycle layer is Hammerspace, a data orchestration partner in the LStore ecosystem, covered alongside Spectra Logic (the tape preservation tier, discussed in §06 below) on the Partners page. Hammerspace is a global data platform that presents a unified namespace over heterogeneous storage and runs policy-driven data placement across the tiers underneath. LStore is one of the tiers Hammerspace orchestrates — the large-capacity persistent tier — and the integration is configured such that LStore presents through an NFS-exported path that Hammerspace treats as one of its storage systems. The result is a deployment in which Hammerspace sees the full namespace, LStore handles the storage durably at the persistent tier, and the policy engine drives placement across the tiers based on access patterns and size rules, moving data on the fast front tiers itself while LStore performs the movement on its own depots and tape.
Scratch, Fast, LStore — volume groups in the orchestrator.
The ACCRE production deployment runs three tiers, each defined as a volume group in Hammerspace, each addressing a different point on the performance-versus-persistence curve. New data starts on the fastest tier and migrates to slower, larger, more durable tiers as it cools. The boundaries between tiers are policy decisions, not architectural ones — the storage underneath each tier is independent storage with its own characteristics, and the orchestration layer makes them act as a single graduated whole.
Fastest, non-durable cache.
Direct-attached NVMe on compute nodes. The high-I/O working layer where most new data lands first. Non-durable by design — the tier exists to absorb write velocity, not to provide retention.
Persistent SSD mid-tier.
Dedicated JBOD depot servers using mirrored disk pairs (avoiding RAID contention). The persistent home for active small files, for hot data sets where frequent-access patterns justify SSD-class latency, and for data pushed off the scratch tier that is below the size threshold for LStore placement.
Large-capacity persistent.
The LStore depot fleet itself, exposed to Hammerspace as an NFS-exported path. Multiple servers can export the same path for high availability, accessible through different IP addresses. The capacity tier for active data large enough to belong here and not on the SSD mid-tier.
The three tiers are not islands. The point of running them under a single orchestrator is that data can move between them on policy, and the orchestrator presents a single namespace to applications regardless of which tier currently holds the bytes. An application writing a new file does not need to choose a tier; the policy engine chooses for it. An application reading an existing file does not need to know which tier holds the data; the orchestrator fetches it from wherever it currently lives. The tiering is configured once at the orchestrator level and operates continuously thereafter.
The LStore tier’s capacity is what makes the model viable for research-computing workloads where total stored volume runs into the petabytes. The Fast tier handles the working set that is below the size threshold and needs SSD-class latency; the Scratch tier handles the write velocity of in-flight computation; the LStore tier handles the long tail of data that is too large to keep on SSD and too active to push to offline archive. The three tiers cover the realistic distribution of access frequency and object size in a way that no single-tier deployment can.
Three Hammerspace objectives that do the placement work.
The placement of data across the tiers is not a continuous balancing act; it is governed by a small set of explicit objectives that the orchestrator applies to files based on their state and age. The objectives are named, configured at the Hammerspace policy layer, and operate automatically against the namespace. The configuration in production at ACCRE uses three of them.
| Objective | Rule |
|---|---|
| accre-create-on-scratch-vg | Directs all newly created data to the Scratch tier (fast NVMe cache). Applied to any file currently being created. The default write path for the deployment. |
| accre-push-to-persistent-tiers | Migrates inactive data off Scratch after 10 minutes of inactivity. Routing is size-based: files ≤ 1 MB move to Fast VG; files > 1 MB move to LStore VG. Applied to any file whose last-use age exceeds the threshold and whose current placement is Scratch. |
| accre-create-on-fast-vg | Alternative initial-placement objective that directs new data to Fast VG directly, skipping Scratch. Used for workloads where the write-amplification benefit of Scratch is not warranted — for example, applications producing many small files where the migration overhead would exceed the cache benefit. |
The size threshold matters. The 1 MB boundary in accre-push-to-persistent-tiers reflects the reality that small files and large files have different storage economics. A small file held on SSD costs a small amount of premium capacity; a large file held on SSD costs a lot. The threshold routes each file to the tier where its storage cost is proportionate to its size, with the Scratch tier serving as the common entry point that absorbs write velocity for both.
The 10-minute inactivity window is similarly chosen. Long enough that files actively being read or rewritten stay on the fast tier where the application sees them at NVMe latency; short enough that the Scratch tier does not fill with cold data and lose its function as a write cache. The choice is configurable, but in production at ACCRE it has settled at 10 minutes after iteration against the actual workload.
What this section is really describing is the depth of policy customization available in the orchestrator. The three objectives shown are the configuration that ACCRE arrived at for its mix of workloads. A different institution with different workload characteristics — more small files, less write velocity, longer working-set residency — would land at different objectives, different thresholds, different tiers. The mechanism is the same; the parameters are tuned to the workload. Unique Checksum’s engagement with institutions deploying LStore includes the workload analysis and policy design that produces the right configuration for the institution’s actual data.
A gap that justifies the tier separation.
The performance gap between the tiers is what justifies running them separately rather than collapsing them. At the qualitative level: the NVMe Scratch tier delivers materially higher sequential throughput than the SSD-based Fast tier, while random small-block performance is closer between the two because at 4 KB block sizes the constraint shifts from media bandwidth to I/O path latency.
The shape of the gap is instructive. Sequential throughput on Scratch is several times that of Fast VG — the gap that justifies running NVMe as a separate tier rather than collapsing it into the SSD persistent layer. Random small-block performance on both tiers is in the same general range, since the dominant constraint at 4 KB block sizes shifts from media bandwidth to I/O path latency and the difference between NVMe and SATA SSD narrows. The placement model takes advantage of this: large sequential workloads benefit substantially from landing on Scratch first, while small-random workloads see less benefit from the cache layer and can reasonably be configured to write directly to Fast VG via the alternative initial-placement objective. The specific numbers from any deployment are hardware-dependent and tend to drift as fleets are refreshed; the shape of the gap is the architecturally stable part, and it is what the placement model is responding to.
The LStore tier’s performance is not shown in the same comparison because it serves a different purpose — HDD-class throughput across a fleet of distributed depots, optimized for capacity-per-dollar and durability through erasure coding rather than for the per-operation latency that defines the SSD tiers. The LStore tier’s performance story is in aggregate — many concurrent operations across many depots, summing to throughput that supports multi-petabyte workloads — rather than in single-stream benchmarks. The reliability characteristics of that tier are covered in detail on the Reliability & Integrity page.
The LStore tier is durable because it is operated.
The tiered orchestration above presupposes that the LStore tier is durable. That durability is not automatic. It is the product of continuous depot operations work — allocation warming, drive replacement, RID management, the operational practice that exercises LStore’s reliability mechanisms against real production failures every day. This section is brief, because the operational detail lives on the Reliability & Integrity page; the role it plays here is to name the dependency.
The relationship between this layer and the Hammerspace tier above it is that Hammerspace can rely on the LStore tier presenting as a durable NFS-exported path because the depot operations work below the NFS export ensures it remains durable. The orchestrator does not need to know about RID management, drive replacement, or warming; the LStore tier handles them. The result is that the tiered lifecycle described in the previous sections can operate against the LStore tier the same way it operates against any other persistent storage — reading, writing, and migrating data without needing to understand the operational machinery underneath.
The detail of the depot operations work — the script inventory, the failure-response procedures, the hardware genealogy of the production fleet — appears on the Reliability & Integrity page. The point worth making here is that the lifecycle layer is downstream of the operations layer. When Unique Checksum engages with an institution to deploy LStore, the design of the depot operations practice is as much part of the engagement as the orchestration policy — because the orchestration policy assumes the operations practice is in place.
Tape as a destination, not a separate system.
The lifecycle does not end at the LStore tier. For data with long retention horizons and access patterns that do not justify keeping it on spinning disk, the destination is tape — integrated into the platform’s tiered placement model rather than handled as a separate offline archive. LStore’s plugin model and per-file segment composition are what make this integration architectural rather than bolted-on, and the underlying tape library management technology Unique Checksum contributes is what makes it operational.
The architectural mechanism is the same one that handles the other tiers: a segment driver. LStore’s exnode can compose segments of different types, and the segment driver for archive operations stages data between active depot allocations and archive-tier destinations. From the application’s view, the file is the same file. From the exnode’s view, its segment composition has changed to point at archive-tier storage. From the depot’s view, the active-tier allocations holding the data have been released after the archive operation completes, and the storage they occupied is returned to the available pool. The pattern matches the inter-tier migrations described in earlier sections; the difference is that the destination tier is tape rather than another disk class.
The tape platform Unique Checksum supports as the LStore archive target is the Spectra Logic TFinity SLC library at LTO-10, with 2.2 exabytes of native capacity per library. The choice of tape platform is documented separately on the Spectra Logic page, which covers the partnership and the tape library’s role in the LStore solution set. What this page contributes is the architectural framing: tape is a tier in the lifecycle, the segment driver model means tape integration is not a separate system from the rest of the platform, and the operations of the tape tier are part of the same continuous practice that operates the disk tiers.
The capability that makes the tape tier operational at production scale is Unique Checksum intellectual property. The tape library management technology was developed inside TiBS over more than two decades of deployment in high-performance and research-computing environments, and is extended into LStore today as part of the platform’s operational tape tier. That tape-library-management IP is one of two streams of the broader Teradactyl IP estate that Unique Checksum now owns and develops — the other being Constancy, the enterprise network backup system in production at ACCRE. Both streams reflect the same operational philosophy: data integrity at scale is produced by engineering the mechanisms that detect, recover from, and prevent degradation, sustained by continuous operational discipline. Further detail on the IP estate appears on the About page.
For institutions whose data has retention horizons measured in decades or whose regulatory or research-reproducibility obligations require offline copies, the tape tier is not an afterthought to the storage platform — it is a fully-supported destination in the lifecycle, with the same architectural treatment as the other tiers and with engineering hardened against the operational realities of running tape libraries as a working tier. The tape integration is part of the platform’s definition, not an add-on to it.
The cost of the architecture, at production scale.
A storage platform’s architectural properties are interesting; its operational economics are what determine whether an institution can sustain it across the multi-year horizons that research-computing workloads operate over. The tiered lifecycle described above produces a measurable cost outcome at ACCRE, and Hammerspace, the orchestration partner, has placed that outcome on the public record.
Reduction in storage cost versus an all-flash storage architecture, attributed by Hammerspace to the LStore-based architecture deployed at ACCRE.
Paraphrased from the public Hammerspace announcement, 20 November 2025. Read the announcement →
The shape of the saving is the shape of the tiering. An all-flash architecture provides uniform high performance at uniform high cost; data that does not need high performance is paying the high-cost premium regardless. The tiered approach matches each file’s placement to its actual access pattern, with the result that the high-performance tier holds only data that benefits from being there, and the bulk of the stored volume sits on capacity tiers whose cost-per-terabyte is appropriate to the access frequency. The 48% figure is the cumulative result of that matching across the deployment’s actual data distribution.
The number is also a useful proxy for the broader economic argument that the lifecycle layer makes. The mechanism that produces the cost saving — matching placement to access pattern through policy-driven migration — only works because the underlying storage platform supports per-file placement decisions and because data can move between tiers under policy without disrupting application access. Both conditions are architectural properties of LStore plus Hammerspace as deployed. The saving is real, the architecture that produces it is documented, and the result is reproducible at other institutions whose data distribution and workload mix resemble ACCRE’s.
Policy is a starting point, not a finish line.
The migration objectives, the size thresholds, the inactivity windows, the tier definitions — all of these are configured once at the orchestration layer and then operate continuously thereafter. But continuous operation is not the same as static configuration. Workloads evolve; data-distribution shapes shift; new hardware enters the fleet and old hardware retires; new tiers become available as media classes change. The lifecycle policy that fit the institution’s workload at deployment time will not fit it indefinitely without revisiting.
The work this implies is not large in absolute terms, but it is real and it is ongoing. The right inactivity threshold today may be the wrong threshold a year from now when the institution’s application mix has shifted. The right size boundary between Fast and LStore tiers today may need adjustment when a new generation of SSD changes the cost-per-terabyte curve. The right composition of tiers today may need expansion when a new tier becomes worth introducing — computational storage, persistent memory, a different archive medium. LStore’s plugin model and per-file segment composition are what make this expansion possible architecturally; the operational practice of revisiting policy as conditions change is what makes it actually happen.
Unique Checksum’s engagement with institutions deploying LStore includes both the initial design of the lifecycle orchestration policy and the ongoing review of that policy against the institution’s evolving workload. The same operational philosophy that underlies the depot operations practice on the Reliability & Integrity page and the integrity work described by Constancy applies here: the mechanisms are necessary, the configuration is necessary, and what completes them is the discipline of operating them continuously against changing conditions. The institutions that get the most from LStore are the ones that treat lifecycle as a practice rather than as a one-time deployment task.
The detail of how Unique Checksum structures that ongoing engagement — the agreement models, the operational cadence, the relationship between Unique Checksum and the institution’s internal storage team — appears on the Engagement Models page that follows.