Why the mapping table cannot be updated in place
An L2P table maintained at 4KB granularity scales directly with capacity: the larger the drive, the less realistic it becomes to flush the whole structure the moment power disappears. There is an order of magnitude between the 15.36TB top capacity of a J750 and the 122.88TB class parts at the other end of the portfolio, and that gap alone decides whether "just write the table out" is still a viable recovery story. Overwriting an entry in place means the old and new values briefly occupy the same physical location — lose power inside that window and what comes back is neither mapping.
Two paths to crash consistency
- Shadow update: the new version is written to a free location and takes effect through a single atomic root-pointer switch. The cost is extra writes to the upper index levels on every commit, growing with how random the updates are.
- Log replay: only the deltas are appended to a journal region, while the table body is checkpointed periodically. The cost is a recovery time equal to replaying everything after the last checkpoint.
In practice the two are combined rather than chosen between. The J750/J770 firmware definition checkpoints the table body, journals the deltas in between, and switches the root pointer only at checkpoint boundaries.
What actually bounds the checkpoint interval
Sparser checkpoints mean lower steady-state write amplification but a longer log to replay; denser ones recover faster but spend normal-mode bandwidth on metadata. The hard limit comes from PLP: hold-up capacitance funds only a bounded number of program operations after power is lost, and whatever sits at the tail of the journal must be committed within that budget. The checkpoint interval is therefore not a freely tunable performance knob — it is a ceiling derived backwards from an energy budget.
Validation that counts
Pulling power while the drive is idle proves almost nothing. Useful injection places the cut inside the critical sections — mid-program, mid-journal-write, mid-checkpoint-switch — and then reconciles host-side write records against on-drive mappings entry by entry once the drive comes back. The J750 and J770 are at the product-definition/EVT stage, and this kind of injection testing runs as a standing item on the JH-E4U-C internal engineering platform rather than as a pre-production spot check.