A Logical Storage Write Can Require Old Data Before New Parity

Define the stripe and the counted transfer

An AI storage proposal may identify host write sizes without explaining the work those writes create inside its parity array. The missing information includes where each write starts, how it overlaps stripes and which existing contents the update calculation needs.

Use one hypothetical healthy RAID 5 layout with five members. Each stripe contains four data chunks and one parity chunk, with parity distributed across members from stripe to stripe. Every chunk is exactly 4 KiB, or 4,096 bytes. A stripe therefore spans 16 KiB of host-addressable data; its additional parity chunk has no separate host data offset.

For this example, every new data chunk is complete and already in RAM. Every required old data or parity chunk is uncached. One chunk read means exactly one 4 KiB member request, and one chunk write means exactly one 4 KiB member request. Treat each compared host write separately, grouping its changes within each stripe and choosing the fewer-transfer option from the two algorithms explained below.

Count only those requests. The model excludes failures, journaling, metadata, retries, compression, merging between host writes and all other overhead. These are educational premises for original arithmetic, rather than observations of an operating array. The chunk size describes this layout, independently of a drive's sector format or NAND units.

Read-others and read-modify-write need different old information

Intel's January 2019 white paper, document 338540-003, explains two parity-update methods on printed page 4. Read-others combines the new changed data with the unchanged data from the stripe. Read-modify-write, or RMW, combines old parity, the old versions of changed data and their new versions. Both then write the changed data and new parity.

One symbolic illustration shows why both can work. At a corresponding bit position in four data chunks A, B, C and D, old parity P equals A XOR B XOR C XOR D. XOR returns one when two input bits differ. Replace A with a new bit a. Read-others obtains new parity as a XOR B XOR C XOR D.

RMW obtains it as P XOR A XOR a. Substituting the old equation for P leaves A twice; those identical bits cancel, leaving a XOR B XOR C XOR D again. Thus RMW can use old A and old P without reading B, C or D. The same cancellation extends to each changed chunk.

The choice changes the old information required, while the intended new parity remains the same. The calculations below compare those dependencies in the stipulated layout; they do not assert that every RAID 5 implementation selects these paths.

References: [I1]

Offset zero: 12 KiB changes three chunks in one stripe

Start a 12 KiB host write at logical byte offset zero, which is also the start of stripe zero. It replaces that stripe's first three 4 KiB data chunks. The fourth data chunk remains unchanged.

Read-others already has the three replacement chunks in RAM. It reads the one unchanged chunk, calculates parity from the complete resulting data set and writes the three new data chunks plus one new parity chunk. That is one read plus four writes: five member transfers, or 5 × 4 KiB = 20 KiB.

RMW would instead need the three old changed chunks and old parity: four reads before the same four writes. Read-others therefore uses fewer transfers in this model. Its 20 KiB total comprises 4 KiB read and 16 KiB written for the host's 12 KiB update.

Offset 12 KiB: the same host bytes change two stripes

Now consider a separate 12 KiB host write starting at logical byte offset 12 KiB, or 12,288 bytes. Its first 4 KiB replaces the last data chunk in stripe zero. Its remaining 8 KiB replaces the first two data chunks in stripe one. The request still supplies three complete chunks, but the changed population is one chunk in one stripe and two in another.

For stripe zero, RMW reads the old changed chunk and old parity, then writes the new data and new parity. Two reads plus two writes make four transfers. Read-others would need three unchanged-chunk reads plus those same two writes, so the model chooses RMW.

For stripe one, read-others reads the two unchanged chunks, then writes the two new data chunks and new parity. Two reads plus three writes make five transfers. RMW would need two old changed chunks and old parity, followed by the same three writes, so the model chooses read-others.

Together, the stripes require four reads and five writes: nine transfers, or 9 × 4 KiB = 36 KiB. That comprises 16 KiB read and 20 KiB written. Moving the starting offset increased both the old information fetched and the parity chunks written, with host input unchanged at 12 KiB.

An aligned 16 KiB write supplies all four new data chunks

Keep the same layout and premises, but consider a separate 16 KiB write beginning at offset zero. All four replacement data chunks for stripe zero are present in RAM. The complete new data set supplies the parity calculation, so no old data or old parity needs to be read.

The array still writes four new data chunks and one new parity chunk: zero old reads plus five writes, totaling 20 KiB. Intel's printed page 5 explains the full-stripe case's absence of additional reads and the remaining parity write.

Compare all three cases at this defined boundary. Aligned 12 KiB used one read and four writes; shifted 12 KiB used four reads and five writes; aligned 16 KiB used zero reads and five writes. The first and third move the same total bytes, but their read/write mixes and host payloads differ. Equal totals do not establish equal completion times.

References: [I1]

Use the example to identify the missing condition

The shifted request is contiguous, yet it updates two partial stripes. A sequential access label therefore does not establish that each update supplies a complete stripe. Even a request equal to the stripe's data size needs its starting alignment established.

The four-data, one-parity layout stays unchanged across the examples. Its protection space requirement cannot select the update path or explain the different read counts. Use the related capacity guide for the separate reconciliation from raw devices to the client's allocation.

Also distinguish total transfers from writes. The shifted case's 36 KiB includes 16 KiB of reads; its modeled member writes total 20 KiB. Neither quantity establishes SSD-internal NAND writing or endurance. The related sector-format and SSD-endurance guides explain those separate boundaries.

Real timing requires evidence about the actual system, including concurrency and completion conditions. Nine transfers cannot be converted into a latency or speed ratio against five merely by dividing their counts. The related performance guide explains how to compare IOPS, byte throughput and response measurements.

Compare proposals by the update conditions their evidence covers

Consider two fictional responses to the same AI storage requirement. Response A supplies protected capacity and a sequential write headline. Response B additionally identifies the member and stripe layout, connects expected request sizes and offsets to the update path, explains the relevant cache and write-combining behavior, and supplies performance evidence for those conditions.

B gives the buyer a basis for judging whether its evidence covers the required work. A leaves the old-input question unanswered; that omission alone does not show that its system is slower. Ask A's storage owner to supply the missing connection rather than applying a universal four-I/O penalty.

The useful supplier return identifies the actual controller or software and applicable version, the relevant workload distribution, and whether old inputs are available without member reads. Have the storage owner explain how the implementation handles those updates, then compare performance evidence with its measurement boundary and completion definition attached. Cached old inputs or combined writes would change the premises used here.

For the original comparison, an aligned 12 KiB result is insufficient evidence for the shifted 12 KiB case simply because host byte counts agree. A 16 KiB result likewise needs its alignment and update conditions retained. This gives the buyer a concrete clarification to request before relying on a headline rate.

Interruption consistency is a separate assessment. The related RAID parity write-hole article covers that requirement, including its versioned PPL and journal discussion; the transfer arithmetic here establishes no crash-protection result.

Bring selected equipment into a defined physical deployment

Once the appointed storage and application owners have resolved the system choice, Leviathan's Complete Physical Infrastructure Deployment service can discuss receiving, rack integration, onsite installation, cabling and physical handoff records for the selected equipment. The existing service and its project inquiry are linked below.

Share a nonconfidential equipment and site summary, approved rack positions and connection requirements, appointed supplier and requested physical stages. Scope and availability must be confirmed for the engagement. Storage architecture, RAID configuration, tuning, data handling, recovery and return-to-service decisions remain with the appointed system owners.