Enterprise SSD — power-loss protection and why it is not optional

Why this matters in production

There is exactly one hardware property that can cause a correctly configured, healthy Ceph cluster to lose data silently, and it is the absence of power-loss protection. Everything else about drive selection is a performance or cost decision. This one is a correctness decision, and it deserves to be treated separately.

What power-loss protection actually does

Every SSD has a volatile write cache — DRAM holding data on its way to flash, and holding the flash translation layer mapping table.

When the operating system issues a write and then a flush, the drive must not report success until the data is durable. A drive with power-loss protection contains capacitors holding enough charge to flush that cache to flash after mains power disappears. A drive without them reports success as soon as the data is in DRAM, because in a desktop that is a reasonable trade.

flowchart TD
  A[BlueStore write + flush] --> B[Drive DRAM cache]
  B --> C{Power lost now?}
  C -->|"PLP: capacitors flush"| D[Data reaches flash — write is durable]
  C -->|"No PLP: cache is volatile"| E[Data lost — but was acknowledged]
  E --> F[Replicas now disagree]
  F --> G[Discovered by deep scrub, days later]

The path on the right is the dangerous one, and it is dangerous precisely because nothing reports an error. The OSD believes it committed the write. Ceph believes the PG is clean. The inconsistency is found later by a deep scrub, at which point determining which replica is correct may not be possible.

Steady-state performance

The second thing enterprise drives buy is honesty about sustained work. Consumer drives quote burst figures achieved into an SLC cache; enterprise drives quote steady-state figures achieved after the cache is irrelevant.

For Ceph this is the number that matters, because the workloads that stress a drive — recovery, backfill, large ingests — run for hours. A drive that does 500 MB/s for ninety seconds and 90 MB/s thereafter is a 90 MB/s drive as far as an OSD is concerned.

Endurance you can plan against

Enterprise drives are specified in DWPD (drive writes per day) or TBW (terabytes written) over a warranty period. Both are usable inputs; DWPD is easier to reason about.

The Ceph arithmetic:

device writes = client writes x replication x write amplification

A pool ingesting 2 TB of client data per day at 3-way replication puts 6 TB per day across the OSDs, plus BlueStore metadata, plus the drive’s internal amplification. Spread across twenty 4 TB drives that is roughly 300 GB per drive per day, or about 0.08 DWPD — comfortable for a 1 DWPD drive.

Do that calculation before purchase. It is usually reassuring, and when it is not, it is much cheaper to know in advance.

Specifying a drive

For any device that will hold OSD data or BlueStore metadata:

• Power-loss protection: required, stated on the datasheet.
• Steady-state random write IOPS: the figure to compare, not burst.
• DWPD: computed against your write budget, with headroom.
• Consistent latency under sustained load: enterprise datasheets often publish this; consumer ones never do.

Quiz

Production discipline

Make power-loss protection a hard requirement on every OSD device and treat a datasheet that does not mention it as a datasheet that answers no. Compare steady-state write figures rather than burst ones, since a Ceph OSD under recovery never operates in the cached regime. Compute DWPD against client writes times replication times amplification before purchase. These three checks take an hour and prevent the two failure modes that hardware choice can introduce into an otherwise correct cluster.

Cross-course references

• Ceph: Part XII (BlueStore) for the flush contract this depends on.
• Ceph: Part LXII (Inconsistent PGs) for what a lost write looks like when scrub finds it.
• Linux: Part XIII (Disks and Block Devices) for the kernel-side flush semantics.