Industry Insights

Choosing SSDs for Object Storage Back Ends: EC Read Amplification, Density and Rebuild Windows

작성: JH Semiconductorobject storage selection / erasure coding read amplification / rebuild window

Object storage writes sequentially with write amplification near unity, so endurance is not the bottleneck; the pressure sits entirely on concurrent small reads created by erasure coding. And doubling drive capacity buys density at the cost of a longer rebuild window.

Start from the shape of the workload

Object storage writes are almost entirely large sequential appends; objects are rarely modified in place once written, and deletion happens at whole-object granularity. That pattern suits SSDs well: writes are naturally aligned, valid-page migration during reclaim is low, and write amplification sits close to unity. The pressure is all on the read side. Erasure coding splits an object into k data and m parity fragments distributed across nodes, so every read becomes a concurrent set of small reads across many drives — and when a fragment's node is unavailable, enough additional fragments must be read to reconstruct, raising read amplification and concurrency together.

Endurance is negotiable, random read is not

With low write amplification and predominantly sequential writes, endurance is not the limiter here; the 1 DWPD over five years planned for J750 is generally more than sufficient. What must hold is random read IOPS and latency stability, because EC fragments commonly land in the tens-to-hundreds of kilobytes range and node-side metadata index lookups stack small reads on top. This is also why QLC holds up in this workload: the Q7 series J760Q and J760QD target object storage, backup and archive with Gen4 QLC, conceding exactly the endurance dimension this workload cares least about in exchange for lower cost per terabyte. Q9's J960Q and J960QD are QLC too, but their positioning centres on AI checkpointing and very large capacity arrays, so they should not be dropped in as archive drives by analogy.

The hidden cost of large drives is rebuild time

Moving from 7.68TB to 15.36TB per drive doubles rack density — and doubles the data that must be rebuilt when a drive fails. Rebuild traffic competes with foreground service for bandwidth, and the longer the rebuild window, the higher the probability of a second failure inside it causing data loss. Selection therefore cannot stop at cost per terabyte; cluster EC parameters, the bandwidth actually allocatable to rebuild, and the target rebuild duration all belong in the same calculation. Raising capacity usually requires tightening m or raising rebuild concurrency in step, or part of the density saving is handed straight back as availability risk.

Matching form factor to the chassis

Storage nodes are typically high-density enclosures with 24 or more bays, where power and airflow budgets are amortised per slot. U.2/U.3 15mm remains the mainstream for installed platforms, and the 18W typical with 22W maximum planned for J750/J770 is a figure you can multiply out to a fully populated chassis. Newer high-density nodes aimed at OCP cloud data centres lean toward E1.S and E3.S, which is the path the FLEX 9 series follows with J100S, J130S, J100E and J130E. All of these figures are planning values at the product-definition/EVT stage. Validating chassis airflow capability against the drive's power curve during selection is far cheaper than relying on thermal throttling as a backstop — when throttling kicks in, the rebuild window is the first thing to suffer.

키워드
object storage selectionerasure coding read amplificationrebuild windowQLC capacity drivesE1.S high-density nodesJH Semiconductor