Glossary
Read/write performance
Read/write performance is how quickly a storage system completes reads and writes, reported separately because the two follow different paths. A read returns data that already exists, from any healthy copy. A write must store and protect new data before the system can confirm it to the application.
Reads and writes side by side
| Read | Write | |
|---|---|---|
| Complete when | One healthy copy, or enough data pieces, has been returned | Every protected piece is stored and its location recorded |
| Effect of data protection | None; extra copies or parity are not read | Each write places more than its own size on the drives |
| Effect of a second site | Served locally | Synchronous copies add the trip to the second site to every write |
| Help from a cache | Large when data is read repeatedly | Limited; data must still reach durable media |
| On flash media | Fast | Slower than reads, and each write adds wear |
The last row is covered under flash storage endurance.
What does data protection add to each write?
The protection scheme sets how much physical writing sits behind each logical write. Keeping three full copies turns 1 TB of new data into 3 TB on the drives. Erasure coding with eight data pieces and four parity pieces stores the same 1 TB as 1.5 TB. Both survive several failures, but the second gives the drives and network half as much to carry. Reads see none of this difference, since they need only one copy or the data pieces. Replication to another site adds a further copy, and when it is synchronous the application waits for that copy too.
Where write cost shows up
- Ingest and backup jobs, which are almost entirely writes and often overrun a backup window sized from read figures.
- Small writes, where recording the location of the data is a large share of the work for each operation.
- Rebuilds after a drive failure, which write regenerated data alongside normal traffic.
- Mixed workloads, where heavy writing takes capacity from reads that were fast when tested alone.
Why one combined figure misleads
A single number for "mixed" performance hides which half the workload depends on. A ratio such as 70 percent reads is only meaningful when it matches how the application actually behaves, and many do not: backup targets and log stores are write-heavy, while content delivery is read-heavy. Benchmarks that report reads and writes on separate lines let each be checked against the workload. A flash cache improves the read line far more than the write line.
Frequently asked questions
Why are writes slower than reads?
A write is confirmed only after every protected piece is stored and recorded, and sometimes after a second site has a copy. A read needs one healthy copy, so it has less to wait for.
Does erasure coding make writes slower than replication?
It adds calculation but writes fewer bytes in total. Which is faster depends on the system and the write size; for large writes, the smaller volume often matters more than the calculation.