ZRAID: Leveraging Zone Random Write Area (ZRWA) for Alleviating Partial Parity Tax in ZNS RAID

Zoned SSDs are cheaper, more predictable flash drives that only allow sequential writes, but building a parity-based RAID from them is awkward — when a write does not fill a whole stripe, the drive must stash a temporary "partial parity" somewhere safe until the rest of the stripe arrives, and the standard fix of logging all these partial parities into a few reserved zones creates a traffic jam and wears the flash out faster; this work from Seoul National University uses a new drive feature, a small rewritable buffer near each zone's write pointer, to tuck each partial parity into its own data zone, spreading the load and letting the temporary data simply expire without ever hitting the flash.

The argument in one glance

Problem

RAID on zoned SSDs must stash a temporary partial parity somewhere

Zoned Namespace (ZNS) SSDs are cheaper, more predictable flash drives that only allow sequential writes. Building parity RAID from them is awkward: a write that does not fill a whole stripe needs a temporary partial parity to protect it until the rest of the stripe arrives, and that must be stored persistently in the meantime.
What people did

Log every partial parity into a few reserved zones

Reserve a small number of dedicated zones and permanently write each partial parity there, keeping it safe until the full stripe is available and the real parity can be computed.
Why it fell short

The reserved zones bottleneck throughput and wear the flash

Funneling partial parities from many data zones into a few reserved zones creates a throughput bottleneck, and permanently writing this short-lived data wastes flash, raises write amplification, and shortens the drive's life. These inefficiencies are the partial parity tax.
This paper's idea

Stash partial parity in each zone's rewritable buffer (ZRAID)

ZRAID uses a new ZNS feature, the Zone Random Write Area (ZRWA) — a small rewritable buffer near each zone's write pointer — to store each partial parity within its own data zone. This spreads the writes across many zones (no bottleneck) and lets the short-lived parity expire in the buffer without ever hitting flash, and it frees ZRAID to use general I/O schedulers. Result: up to 34.7 percent higher write throughput and up to 1.6 times less flash write amplification.

Why this problem is worth solving

Zoned SSDs are a rising storage technology precisely because they strip out expensive internal machinery, but that shift moves work onto the software above them.

A conventional SSD presents a simple interface — read or write any block at any address — but internally it must do a great deal of hidden work to sustain that illusion on flash, which cannot be overwritten in place: it maintains a large flash translation layer mapping logical to physical locations, over-provisions capacity, and runs garbage collection, all of which add cost and cause unpredictable performance. A Zoned Namespace (ZNS) SSD reduces this overhead by changing the interface. It divides the drive into zones that accept only sequential writes, and it exposes a write pointer for each zone that the host must write at, advancing as data is written; the host also takes over managing when zones are reset for reuse, a job the drive’s flash translation layer used to do. This pushes more management onto the host, but in exchange the drive is cheaper, more space-efficient, and more predictable in performance, which is why ZNS SSDs are attractive for data centers. The catch is that everything above the drive now has to respect the sequential-write, host-managed model.

That constraint turns a routine reliability feature — parity RAID — into a genuinely hard problem on zoned drives.

Data centers deploy drives in arrays and use RAID for performance and reliability, typically with parity: the data is spread across the drives in stripes, and an extra parity block per stripe lets the array reconstruct data if a drive fails. Parity is computed over a full stripe, but real writes do not always fill a whole stripe at once. A write that stops short leaves an incomplete, partial stripe, and to protect that data before the stripe is finished, the RAID layer must compute a partial parity over what has been written so far. This partial parity is inherently temporary — it will have to be recomputed as the remaining data for the stripe arrives — so it cannot be placed in the stripe’s final parity slot yet. It must instead be held somewhere persistent until the full stripe is complete, because if power fails in between, the partial stripe would be unrecoverable. On a ZNS drive, where you cannot simply overwrite a block in place, storing and repeatedly updating this transient data is awkward, and the cost of doing it badly — extra writes, bottlenecks, and shortened drive life — is what the paper names the partial parity tax.

What people did before, and where it broke

Buffer data in host memory until the stripe is full. Hold incoming writes in the RAID driver, compute the full parity once the stripe completes, and write only that. Where it broke. A sudden power failure loses the buffered data, which is unacceptable in a data center that must not lose acknowledged writes.
Buffer safely in non-volatile memory. Use persistent memory like Optane to hold partial state without risking power-failure loss. Where it broke. It adds cost and depends on specialized hardware that has since been discontinued, so it is not a durable general solution.
Log partial parity into a few reserved zones (RAIZN). Dedicate a small number of zones and permanently write every partial parity there for safety. Where it broke. Partial parities from many data zones funnel into few reserved zones, bottlenecking write throughput, and permanently storing this short-lived data wastes flash and raises write amplification, shortening drive life.
Accept the ZNS sequential-write scheduler limits. Use the special I/O scheduler that reorders writes to keep them sequential, as ZNS requires. Where it broke. That scheduler restricts queue depth, capping the write parallelism and throughput the array can achieve.
The gap. No design stored the transient partial parity without a central bottleneck, without wasting flash on short-lived writes, and without the scheduler limits. Providing that, using the drive’s Zone Random Write Area, is what ZRAID does.

How ZRAID works

From logging partial parity in reserved zones to using each zone's rewritable buffer

↓ →
new
↓ →
new
↓ →
new
↓ →
new
↓ →
new

The idea

Spread the transient parity across every zone instead of funneling it into a few. The core inefficiency of the prior design is centralization: partial parities from all the data zones are logged into a handful of reserved zones, so those few zones become a write bottleneck for the whole array. ZRAID’s reorganization is to keep each partial parity local — it lives in the buffer of the very data zone whose incomplete stripe it protects — so the partial-parity writes are distributed across all the data zones and no small set of zones is overwhelmed. Eliminating a central chokepoint by distributing state to where it belongs, so load spreads evenly across the array rather than concentrating on a reserved region, is the same move the disaggregated-RAID work covered elsewhere on this site makes, rethinking how RAID lays out and directs its traffic across modern storage so that no single component becomes the funnel through which everything must pass.

Exploit a device feature so short-lived data never becomes a permanent cost. The second inefficiency is that logging partial parity permanently writes data that is inherently temporary, wasting flash and inflating write amplification. ZRAID leverages the Zone Random Write Area, a new ZNS feature that gives each zone a small rewritable buffer, backed by durable high-endurance storage, in which data can be updated in place and, crucially, when overwritten simply expires in the buffer rather than being flushed to the main flash. By storing the partial parity there and letting the arriving stripe data overwrite it, ZRAID makes the transient parity vanish at no flash cost. Reaching into the storage device’s own mechanisms to handle short-lived data cheaply, rather than paying the full cost of a permanent write for something that will soon be discarded, is the same discipline the learned flash-translation-layer work covered elsewhere on this site follows, managing the drive by exploiting how the device actually behaves so that avoidable writes and overheads are engineered away instead of tolerated.

Remove an ordering constraint to unlock parallelism. Because ZNS zones normally demand strictly sequential writes, RAID on them has been forced to use a special I/O scheduler that reorders writes to preserve that order, and that scheduler caps the queue depth, limiting how many writes can be in flight and throttling throughput. Since the ZRWA permits in-place, non-sequential writes within its window near the write pointer, ZRAID is freed from that strict requirement and can use general-purpose schedulers with higher queue depth, letting more writes proceed concurrently and lifting throughput further. Relaxing a rigid ordering requirement that a storage stack imposed, so the underlying parallelism of the device can finally be used, is the same goal the barrier-enabled flash I/O work covered elsewhere on this site pursues, reworking how write ordering is enforced so that the stack stops serializing operations that the hardware could otherwise carry out concurrently.

Following a partial write through ZRAID

Protecting an incomplete stripe with the Zone Random Write Area

A trace of ZRAID handling an unaligned write on a ZNS RAID array, following the paper's ZRWA-based design.

Step 1 of 5

A write leaves a stripe incomplete

An application writes data that does not fill a whole RAID stripe, so the array has a partial stripe that must be protected before the rest of its data arrives, in case of a power failure.

Parity is defined over a full stripe, which is not yet complete.

Why it works

Local storage removes the central bottleneck. Because each partial parity lives in its own data zone’s buffer rather than a shared reserved area → partial-parity writes are spread across all zones → so no small set of zones is overwhelmed and throughput rises.
Expiring buffer data avoids permanent writes. Because overwritten data in the ZRWA expires without being flushed to main flash → the inherently short-lived partial parity is discarded at no flash cost → so write amplification drops and the drive lasts longer.
In-place updates fit transient parity perfectly. Because the ZRWA allows in-place updates near the write pointer → the partial parity can be updated and then overwritten in place as the stripe fills → so the awkward can-not-overwrite constraint of ZNS no longer forces logging to a separate area.
Relaxed ordering enables higher queue depth. Because ZRWA permits non-sequential writes in its window → ZRAID can use general schedulers instead of the queue-depth-limited ZNS one → so more writes are in flight concurrently and throughput improves further.
Careful pointer management keeps it safe. Because the write pointer is the key recovery indicator → advancing it deliberately preserves a consistent recovery point → so the throughput and lifetime gains do not come at the cost of reliability under power or device failure.

What it costs (trade-offs and scope)

It depends on ZNS drives supporting ZRWA. ZRAID’s whole mechanism rests on the Zone Random Write Area feature of the ZNS Command Set. Drives without ZRWA, or with a very small ZRWA window, cannot use the approach as designed, though ZRWA is a standardized and increasingly available feature.
The rewritable buffer is small and near the pointer. ZRWA offers only a confined region adjacent to the write pointer (for example around a megabyte on a tested drive), so the partial parity must fit within that window and be resolved as the stripe fills; workloads with unusually large or long-lived partial stripes stress that constraint.
Correct write-pointer management is delicate. Because the write pointer is the crux of recovery, ZRAID must advance it carefully and avoid data being overwritten by partial parity; getting this ordering right is essential and is a nontrivial part of the design rather than a free benefit.
Gains vary with the workload’s alignment. The improvements come from handling partial stripes better, so workloads that mostly write full, stripe-aligned data have fewer partial parities to begin with and would see smaller gains; the reported ranges (up to 34.7 percent on a microbenchmark, an average of 14.5 percent on a database workload) reflect this spread.
It is a software RAID layer with its own management. ZNS already shifts space management to the host, and ZRAID adds RAID logic on top; it must manage zones, recovery, and scheduling correctly across real drives, which is engineering that must be maintained, though the source is openly released.
Robustness rests on the ZRWA backing being non-volatile. The safety of storing partial parity in the ZRWA relies on its backing storage being durable through power loss; the approach assumes that property of the device, which is how ZRWA is specified but is a dependency to keep in mind.

The evaluation

Ways to handle partial parity in ZNS RAID

Property	Host-memory buffering	Reserved partial-parity zones (RAIZN)	ZRAID (ZRWA)
Survives power failure
Where partial parity is stored
Throughput bottleneck	None, but unsafe
Extra flash writes for transient parity	None
I/O scheduler	Not applicable

Ways to handle partial parity in a ZNS RAID array, as compared in the paper. Buffering incoming data in host memory until a stripe completes avoids extra writes but loses data on a power failure, unacceptable for a data center. Reserving a few dedicated zones and permanently logging every partial parity there (as in RAIZN) is safe but creates the partial parity tax: partial parities from many data zones funnel into few reserved zones, bottlenecking throughput, and permanently writing this short-lived data wastes flash and raises write amplification. ZRAID instead exploits the Zone Random Write Area (ZRWA), a new ZNS feature giving each zone a small durable buffer near its write pointer that allows in-place updates and whose overwritten data expires without being flushed to flash. ZRAID stores each partial parity in the ZRWA of its own data zone, distributing the writes across all zones (removing the bottleneck) and letting the arriving stripe data overwrite the obsolete parity at no permanent flash cost (cutting write amplification). Because ZRWA allows non-sequential writes near the pointer, ZRAID can also use general I/O schedulers with higher queue depth instead of the ZNS-limited one, further raising throughput, while managing the write pointer carefully for power- and device-failure recovery. Evaluated on real ZNS SSDs, ZRAID improves write throughput by up to 34.7 percent in the fio microbenchmark and an average of 14.5 percent in db_bench on RocksDB (13 to 48 percent over existing ZNS RAID overall), with up to a 1.6 times reduction in flash write amplification; the source is open.Underlined values explain themselves when clicked.

Where this stops working

What to keep in mind

ZRAID is a tidy, well-targeted storage-systems result that solves a specific pain point by cleverly exploiting a new device feature. The context is the rise of Zoned Namespace SSDs, which make flash cheaper and more predictable by dropping the block interface’s hidden machinery in favor of sequential-write zones with a host-managed write pointer. That efficiency comes at the cost of making everything above the drive respect the sequential model, and parity RAID exposes the friction sharply: a write that does not fill a stripe leaves a partial stripe needing a temporary partial parity, which must be kept persistent and repeatedly updated until the stripe completes. The prior approach of logging every partial parity into a few reserved zones is safe but incurs what the authors aptly name the partial parity tax: a many-to-few write bottleneck, and permanent flash writes for data that is inherently short-lived, inflating write amplification and shortening drive life. ZRAID’s insight is to use the newly standardized Zone Random Write Area, a small durable rewritable buffer near each zone’s write pointer whose overwritten contents expire without reaching flash, to hold each partial parity inside its own data zone. That single move distributes the writes across all zones (killing the bottleneck), lets the stripe’s arriving data overwrite the obsolete parity for free (cutting write amplification), and, because ZRWA allows in-place writes, frees ZRAID to use general I/O schedulers with higher queue depth for more throughput. The measured gains on real drives are solid: up to 34.7 percent higher write throughput and up to 1.6 times less write amplification, with the code open-sourced. Read the scope carefully. The approach depends entirely on drives supporting ZRWA and on its small window near the pointer; the write-pointer management is delicate because it underpins power- and device-failure recovery; the gains depend on how much of the workload creates partial stripes; and the safety assumes the ZRWA backing storage is genuinely non-volatile. The durable idea is that when a device exposes a new low-level capability, the biggest wins can come from recognizing that a costly software workaround maps perfectly onto it — here, transient parity onto an expiring in-place buffer — turning a tax into nearly free.

Background

Why host-managed flash keeps reshaping storage software

It helps to see ZRAID within a broader shift in how flash storage is managed: away from drives that hide all their complexity behind a simple block interface, and toward drives that expose their structure and hand responsibility to the host software, in exchange for lower cost and more predictable performance. Zoned Namespace SSDs are a leading example, and the whole storage stack above them — filesystems, RAID, schedulers — has to be rethought to fit the sequential-write, host-managed model, which is both a burden and an opportunity to remove overheads the old interface forced. The deduplication-over-SSD-arrays work covered elsewhere on this site reflects the same pressure to strip management overhead out of flash arrays, pursuing efficiency by rethinking how storage services are implemented over modern SSDs rather than accepting the costs of a legacy design. The common thread is that as flash drives expose more of themselves, the software that manages them can either inherit the old inefficiencies or exploit the new interfaces to eliminate them, and the interesting work is increasingly in that co-design between host software and device capabilities. ZRAID is a sharp instance: a feature added to the ZNS command set to relax its own write constraints turns out to be exactly what a RAID layer needs to make its most awkward operation cheap. As host-managed and zoned storage spreads, this pattern of matching a software problem to a newly exposed device mechanism is likely to keep driving storage-system design.

If you remember only three things

1. Zoned Namespace (ZNS) SSDs cut the internal overhead of conventional flash drives by dividing storage into zones that accept only sequential writes and exposing a write pointer, handing space management to the host; this makes them cheaper and more predictable, so data centers adopt them, and data centers use RAID for reliability. But parity RAID on ZNS is awkward because of partial parity: parity is defined over a full stripe, yet a write that does not fill a stripe leaves an incomplete partial stripe that needs a temporary partial parity to protect it until the rest of the stripe arrives. That partial parity is transient (it changes as more data comes) so it cannot go in the final parity slot yet, and it must be kept persistent in the meantime in case of power failure. Prior systems (RAIZN) reserve a few dedicated zones and permanently log every partial parity there, which funnels writes from many data zones into few reserved ones (a throughput bottleneck) and permanently writes short-lived data (wasting flash, raising write amplification, shortening drive life) — the partial parity tax.
2. ZRAID is a software ZNS RAID layer that uses the Zone Random Write Area (ZRWA), a newly added ZNS feature giving each zone a small durable rewritable buffer near its write pointer that allows in-place updates and whose overwritten data expires without being flushed to main flash. ZRAID stores each partial parity in the ZRWA of the very data zone it protects, which has three benefits. First, it distributes partial-parity writes across all the data zones instead of funneling them into a few reserved zones, removing the throughput bottleneck. Second, when the rest of the stripe arrives it overwrites the obsolete partial parity in the ZRWA, and because overwritten ZRWA data expires without reaching flash, the transient parity costs no permanent flash write, cutting write amplification and extending drive life. Third, because ZRWA permits non-sequential in-place writes near the pointer, ZRAID no longer needs the special ZNS scheduler that enforces sequential writes and limits queue depth, so it can use general I/O schedulers with higher queue depth for more throughput. It manages the write pointer carefully because it is the key indicator for recovery after power or device failure.
3. Evaluated on real ZNS SSDs, ZRAID improves write throughput by up to 34.7 percent in the fio microbenchmark and an average of 14.5 percent in db_bench on RocksDB (13 to 48 percent over existing ZNS RAID overall), with up to a 1.6 times reduction in flash write amplification, and the source code is open. Scope: it depends on drives supporting ZRWA and on its small window near the write pointer; the write-pointer management is delicate because it underpins failure recovery; the gains depend on how much of the workload creates partial stripes (stripe-aligned writes benefit less); and the safety assumes the ZRWA backing storage is genuinely non-volatile. The durable lesson is that when a storage device exposes a new low-level capability, a large win can come from recognizing that an expensive software workaround maps perfectly onto it — here, transient partial parity onto an expiring in-place buffer — converting a costly tax into a nearly free operation.

Check yourself

Check your understanding

1. What is partial parity, and why is it a problem on a ZNS RAID array?
2. Why does the prior approach of logging partial parity into a few reserved zones incur a "partial parity tax"?
3. How does ZRAID use the Zone Random Write Area (ZRWA) to alleviate the partial parity tax?
4. What did ZRAID achieve, and what are its main limitations?

Sources

The paper is “ZRAID: Leveraging Zone Random Write Area (ZRWA) for Alleviating Partial Parity Tax in ZNS RAID” by Minwook Kim, Seongyeop Jeong, and Jin-Soo Kim, published at ASPLOS 2025, DOI 10.1145/3669940.3707248. All authors are at Seoul National University, and the source code is available at github.com/snu-csl/zraid.

This explainer is based on the full text of the paper, obtained from the authors’ open-access copy (the CC-BY version) hosted on the Seoul National University Computer Systems Laboratory publications page. The problem framing (Zoned Namespace SSDs reducing the block-interface overhead of conventional SSDs via sequential-write zones with a host-managed write pointer; the challenge of partial parity for incomplete stripes in ZNS RAID; and the partial parity tax of prior approaches, including host-memory buffering risking power-failure data loss, non-volatile-memory buffering adding cost and depending on discontinued hardware, and RAIZN’s reserved-zone logging causing a many-to-few throughput bottleneck plus wasted flash and write amplification), the ZRWA feature (the Zone Random Write Area in the NVMe ZNS command set providing a small non-volatile in-place-writable buffer near the write pointer, backed by high-endurance storage, whose overwritten data expires without being flushed to main flash), the ZRAID design (storing each partial parity in the ZRWA of its own data zone to distribute writes and avoid the bottleneck; letting arriving stripe data overwrite the obsolete parity so it expires at no flash cost; using general I/O schedulers with higher queue depth instead of the queue-depth-limited ZNS scheduler; and managing the write pointer carefully for power- and device-failure recovery), and the results (up to 34.7 percent higher write throughput in the fio microbenchmark, an average of 14.5 percent in db_bench on RocksDB, 13 to 48 percent over existing ZNS RAID overall, and up to a 1.6 times reduction in flash write amplification, on real ZNS SSDs) are all drawn directly from the paper. Background explanations of SSDs, the flash translation layer, RAID and parity, stripes, write amplification, and I/O schedulers are standard and provided to make the paper’s contribution understandable.