---
title: Elastic Solid-State Drive (ESSD)
url: https://www.emergentmind.com/topics/elastic-solid-state-drive-essd
type: topic
---

# Elastic Solid-State Drive (ESSD)

Searching arXiv for the cited ESSD-related papers to ground the article in current literature.
Elastic Solid-State Drive (ESSD) denotes a family of solid-state storage systems in which elasticity is exposed at different layers of the storage stack. In current research usage, the term encompasses cloud-based elastic block storage offered through a storage-compute disaggregated architecture, memory-semantic SSDs that expose both byte and block interfaces via PCIe or CXL, and CXL SSDs that migrate storage-path computation dynamically between device and host. A related line of work extends elasticity to RAID layout selection by exploiting runtime data compressibility. Taken together, this literature frames ESSD not as a single standardized device class, but as a set of architectures that make storage behavior adaptable in provisioning, access granularity, or compute placement [2508.17372] [2501.04993] [2604.02442] [2209.04432].

## 1. Terminological scope and architectural variants

The recent literature uses ESSD in several technically distinct but structurally related ways. In cloud systems, elastic block storage (EBS) “furnishes users with storage capabilities through the elastic solid-state drive (ESSD).” In file-system and firmware research, “memory-semantic SSDs (M-SSDs)/ESSDs” support both byte and block access granularity via PCIe or CXL. In computational storage research, elasticity is defined as “the dynamic ability to migrate computation between the device (CXL SSD) and the host CPU at runtime, in response to changing thermal, power, or workload conditions” [2508.17372] [2501.04993] [2604.02442].

| ESSD usage in the literature | Principal mechanism | Representative paper |
|---|---|---|
| Cloud-based ESSD | Storage-compute disaggregation and provisioned virtual block storage | [2508.17372] |
| Memory-semantic ESSD | Dual byte/block access granularity via PCIe or CXL | [2501.04993] |
| Elastic CXL SSD | Reversible compute using migratable storage actors | [2604.02442] |

This heterogeneity matters because identical terminology can mask different bottlenecks. Cloud ESSDs are dominated by remote and virtualized I/O behavior; memory-semantic ESSDs require file-system and firmware co-design for byte persistence; elastic CXL SSDs center on runtime placement of storage-side compute. A plausible implication is that ESSD should be interpreted as a cross-layer design objective rather than a single hardware form factor.

## 2. Cloud ESSDs as disaggregated block storage

Cloud-based ESSDs are studied as remote block devices exposed through a storage-compute disaggregated architecture. A comprehensive characterization examined Amazon AWS io2 and Alibaba Cloud PL3 against a local Samsung 970 Pro using FIO across I/O sizes from 4 KB to 256 KB, queue depths from 1 to 32, random and sequential access patterns, and mixed read/write ratios. The paper distilled an “unwritten contract” into four observations and five implications for cloud storage users [2508.17372].

The first observation is that “the latency of ESSDs is tens to a hundred times higher than that of SSD when I/Os are not well scaled up.” For small or low-queue-depth workloads, ESSD average latency could be 16.7–47.9× higher and p99.9 latency 99.4–104.2× higher than that of local SSDs. The second observation is that garbage-collection impact “appears much later or even disappears”; in sustained random writes, the local SSD dropped to approximately 149MB/s from more than 2GB/s after 90% capacity utilization, whereas the ESSDs maintained high throughput for nearly 2.5–3× the nominal capacity written before any drop, and one device showed almost no GC-induced drop within the experiment’s write volume. The third observation is that random writes can outperform sequential writes on ESSDs, with maximum gains of 1.52× on AWS and 2.79× on Alibaba. The fourth is that maximum bandwidth is deterministic and no longer sensitive to the access pattern, remaining tightly capped at the provisioned maximum such as 1.1 or 3.0 GB/s [2508.17372].

These observations are explicitly described as counter-intuitive relative to local-SSD expectations. The resulting guidance is correspondingly different from conventional SSD tuning: scale I/O sizes and queue depths up as much as possible; reconsider GC-mitigation techniques designed for local SSDs; rethink efforts to force writes to be sequential; smooth I/O traffic to avoid bursts that exceed the provisioned throughput; and re-evaluate I/O reduction techniques such as compression and deduplication. This suggests that ESSD-aware cloud software should not inherit local-SSD assumptions unchanged.

## 3. Memory-semantic ESSDs and dual-granularity file systems

Memory-semantic ESSDs expose both byte and block access granularity while retaining the persistence properties of SSDs. ByteFS was developed by “rethinking the design primitives of file systems and SSD firmware to exploit the advantages of both byte and block-granular data accesses.” It supports byte-granular data persistence, extends core file-system data structures for dual byte/block access, and uses adaptive interface selection based on data structure and access pattern [2501.04993].

At the file-system level, ByteFS reorganizes metadata so that structures such as inodes can be split into upper and lower regions, with the lower region optimized for frequent, small updates using atomic byte writes. For cached dirty pages, modified-ratio logic determines whether a page should use the byte or block interface; if dirty cachelines in a page are less than \(1/8\) (512B of a 4KB page), ByteFS uses the byte interface, otherwise the block interface. The system also uses copy-on-write with AVX2 for fast XOR-based diffing between original and modified pages. These mechanisms are designed to reduce I/O amplification while preserving essential file-system properties [2501.04993].

Persistence and crash consistency are handled through battery-backed SSD DRAM and a firmware-level transactional log. After MMIO stores, the system performs `clflush/clwb`, then issues a zero-byte read to force PCIe flush of posted writes. Byte-level writes are first appended to a log-structured region in SSD DRAM rather than sent directly to flash. Each update is tagged with a transaction ID, and commit is performed with a custom NVMe `COMMIT(TxID)` while maintaining a transaction table and log in DRAM. Recovery after crash takes approximately 4.2 s, consisting of 0.9 s to load DRAM and 2.7 s to scan the log and commit entries [2501.04993].

The firmware uses SSD DRAM, for example 256 MB, as a log-structured buffer to coalesce byte-granular updates before flash programming. All byte writes are sequentially appended and aligned to 64B cachelines. A three-layer skip list indexes 16MB partitions, logical page addresses, and per-page modified offsets and lengths. When log utilization exceeds 85%, background cleaning coalesces dirty byte ranges, merges pages, and writes out full flash pages; uncommitted log updates are migrated as needed. ByteFS also coordinates caching by avoiding page-level cache duplication: the host maintains the page cache for read locality, while SSD DRAM is reserved entirely for the log-structured write buffer [2501.04993].

The reported gains are substantial but narrowly defined by this dual-granularity model. Compared to state-of-the-art file systems for non-volatile memory and conventional SSDs, ByteFS improves application throughput by up to 2.7× and reduces write traffic to SSDs by up to 5.1×. It also reduces flash writes by 2.9×–3.2×. For ESSD design, the significance is that byte accessibility alone is insufficient; the storage stack must also provide firmware-level coalescing, transactional persistence, and host-device cache coordination.

## 4. Reversible compute and CXL-based elastic SSDs

A different ESSD interpretation treats elasticity as runtime reversibility of storage-side computation. WIO argues that “storage-side compute should be reversible: computation should migrate dynamically between host and device based on runtime conditions.” The system realizes this principle on CXL SSDs by decomposing I/O-path logic into migratable storage actors compiled to WebAssembly, with actor state shared through coherent CXL.mem regions [2604.02442].

The execution unit is the WebAssembly storage actor, a lightweight, dataflow-oriented module for operations such as compression, parsing, and checking. The same binary code runs on host x86 or device ARM cores, and each actor has a linear-memory sandbox that provides isolation, context serialization, and portability. Actor state is divided into compact control state and shared persistent state: the control state, including instruction pointer, stack, and locals, is approximately 8 KB and migratable, whereas long-lived structures such as counters and LRU lists are kept in a CXL.mem-mapped persistent memory region. The design uses a 32GB PMR for shared actor state, submission and completion queues, and DMA buffers [2604.02442].

Migration is performed by a zero-copy drain-and-switch protocol. New requests are first routed to the destination, in-flight work is drained on the source, the actor’s control state is checkpointed to PMR, and a doorbell interrupt activates the actor at the destination using the same shared state. The reported migration cost is under 50 microseconds, with no I/O stall. This is the central mechanism by which WIO converts static storage-side offload into elastic placement [2604.02442].

Placement is governed by an agility-aware scheduler that samples runtime conditions every 10ms. The sampled signals include host CPU frequency, power via RAPL, and queue depth, together with device temperature and utilization. The simplified policy uploads actors to the host if the device is hot, specifically \(T > 75^\circ\mathrm{C}\), and the host has headroom; offloads actors to the device if the host is loaded or high-power and the device is cool; and degrades request rate rather than migrates when both approach limits. Actors are labeled as latency-sensitive or best-effort, and a minimum residency interval avoids thrashing [2604.02442].

The performance results emphasize thermal and power elasticity rather than isolated raw speed. The abstract reports “up to 2× throughput improvement and 3.75× write latency reduction without application modification.” In RocksDB, write-ahead-log latency drops from 45μs on NVMe to 12μs on WIO. With CXL.mem and MWAIT, reported read latency is 18.5μs and write latency 7.6μs, with read IOPS 114,407 versus 9,980 and write IOPS 128,415 versus 40,559; host CPU utilization drops from 100% to 35% at queue depth 1. The system also scales to 652K read IOPS and 577K write IOPS, while 8B and 512B writes complete in 0.47–0.61μs. WIO’s broader contribution is to replace “hard thermal cliffs” with elastic trade-offs under sustained load [2604.02442].

## 5. Compression-aware elasticity at the RAID layer

Elasticity can also be expressed above the individual SSD, at the redundancy and layout layer of storage arrays. Elastic RAID studies SSDs with built-in transparent hardware compression on each 4KB LBA block and shows that runtime user-data compressibility can be used to convert dynamically between RAID 5 and RAID 10 while maintaining the same effective storage capacity. Although this is a RAID rather than a single-device ESSD mechanism, it extends the ESSD theme of runtime adaptation based on storage-state conditions [2209.04432].

The core mechanism is fine-grained stripe-level conversion enabled by “Bloated Stripe Allocation.” The logical address space of each SSD is partitioned into large segments, each twice as large as a RAID 5 stripe, and each segment is split into two slots. Under RAID 5, only slot-1 is used and slot-2 is trimmed. Under RAID 10, both slots store user data in mirrored form, with no parity block. Conversion is performed per stripe: RAID 5 to RAID 10 copies data strips from slot-1 to slot-2 in a skewed pattern and trims old parity or unused blocks; RAID 10 to RAID 5 calculates and writes new parity in slot-1 and trims slot-2. The paper states that these actions are atomic and avoid in-place overwrite [2209.04432].

Conversion policy combines reactive and proactive triggers. Storage utilization thresholds can increase or decrease RAID 10 coverage, while workload-locality shifts can move hot stripes into RAID 10. Stripe selection uses hot/cold identification based on per-stripe access statistics, for example with Second-Chance or LRU, and can also incorporate per-stripe compressibility if the SSD exposes compression-rate information. The design further observes that parity may compress less effectively than user data, so some stripes may be converted autonomously to RAID 10 when doing so reduces physical space usage [2209.04432].

A Linux software-based prototype was implemented in modified MDRAID, with a multithreaded background conversion engine, a segment map or bitmap to track stripe state, a write journal, and throttling to limit interference with foreground I/O. Relative to a baseline software RAID 5, the system improves 4KB random write IOPS by 42% and degraded-mode 4KB random read IOPS by 46% when conversion from RAID 5 to RAID 10 covers 60% of user data. At 20% conversion, the gains are 10% and 12%, respectively. The paper also reports conversion throughput of 3.1 GB/s with 8 threads for RAID 5→10 and up to 6.4 GB/s with 24 threads, while keeping foreground I/O impact below 5% when background conversion is limited to sensible rates such as 200 MB/s [2209.04432].

## 6. Shared themes, misconceptions, and implications

Across these architectures, ESSD research repeatedly rejects assumptions inherited from conventional local NVMe SSDs. One misconception is that SSD latency is intrinsically low regardless of deployment context; cloud ESSDs show that when I/O is not scaled up, latency can be tens to a hundred times higher than on a local SSD. A second is that random writes are necessarily worse than sequential writes; on characterized cloud ESSDs, random writes can be faster. A third is that garbage collection must dominate long-running write behavior; cloud providers can mask or defer GC effects through backend resource management. A fourth is that static offload is the natural form of computational storage; WIO instead argues for reversible storage-side compute to avoid thermal and power cliffs [2508.17372] [2604.02442].

The literature also narrows what “elasticity” means operationally. In cloud ESSDs, elasticity is primarily provisioned bandwidth and disaggregated access. In memory-semantic ESSDs, it is dual-granularity access combined with persistence-aware firmware. In CXL computational storage, it is live migration of storage-path logic between device and host. In compression-aware RAID, it is dynamic conversion between redundancy layouts based on runtime compressibility. This suggests that ESSD is best understood as a control problem over placement, granularity, and redundancy rather than merely a capacity-scaling property.

A further implication is methodological: direct comparison of headline metrics across ESSD papers is often misleading because the systems optimize different layers and expose different interfaces. For example, the deterministic bandwidth cap of cloud ESSDs, the byte-write persistence path of ByteFS, the thermal scheduler of WIO, and the stripe-conversion engine of Elastic RAID are not substitutes for one another. They are complementary attempts to make solid-state storage adapt to runtime conditions without changing the logical role of storage in upper-level software. On that reading, ESSD research is progressively recasting SSD design as cross-layer orchestration among host software, firmware, interconnect semantics, and device-side resource limits.

Source: https://www.emergentmind.com/topics/elastic-solid-state-drive-essd