Two Different Events
"Pulling a drive" in a data centre covers two distinct cases. An orderly removal is initiated by chassis management: the host stops issuing new commands, waits for the queues to drain, uses NVMe Shutdown Notification so the drive can flush its mapping table, and only then brings the PCIe link down. A surprise removal gives no warning at all — the link layer sees Presence Detect toggle while the controller may be halfway through a page program. Neither path may corrupt data; the difference is only in how many steps stand between the event and a usable drive.
What the Hold-Up Window Really Has to Cover
The power-loss-protection window is short. Once the input rail falls below the undervoltage threshold, the energy store must keep the controller alive long enough to commit acknowledged write-buffer data and any in-flight L2P pages to NAND. The binding constraint is not how much energy is stored but how much unflushed state remains at that instant, which is why metadata is journalled incrementally: checkpoints are written periodically during operation so only the trailing log needs persisting on power loss. The planned 18 W typical and 22 W maximum figures for J750/J770 feed straight into energy-store sizing — higher peak draw means more stored energy for the same hold-up time, and pinning down that relationship is exactly the kind of data CORE 7 is gathering at the product-definition/EVT stage.
Where the Time Goes on Power-Up
Recovery after an abnormal reset has four stages: PCIe link retraining to Gen4 x4, controller self-test and firmware load, L2P reload from the last checkpoint plus log replay, and rebuilding I/O queues and namespace context. The first two are largely fixed cost. The third scales with capacity — the mapping table of a 15.36TB SKU is eight times that of a 1.92TB SKU — so log replay must be sharded per channel and replayed in parallel, or ready time degrades linearly at the high capacity points. To the layer above, this interval is simply a window in which the device is absent, and it determines whether a Ceph OSD or RAID group starts rebalancing.
Read Ready Time as a Distribution, Not a Mean
A single passing functional test proves nothing here. The workable method is repeated reset under sustained random write load, with two confirmations after every power-up: a full-drive data consistency comparison showing that no acknowledged command was lost, and a journal integrity check showing that replay start and end points line up. What gets recorded is the whole ready-time distribution, because operations teams debug against the slowest occurrences, not the average. The same case set is repeated across capacity points to confirm that parallel replay genuinely flattens the influence of capacity on ready time.
A Correct Drive Is Not a Working System
Backplane power sequencing on U.2/U.3, whether Refclk is independent, and how the BIOS handles Surprise Down all change observed behaviour — move the same drive into a different chassis and the absence window can look nothing alike. Judging whether a drive is power-fail safe by checking that PLP appears on a feature list is therefore nowhere near enough; what matters is the shape of the curve it leaves behind after both reset paths have been driven to completion on the target platform.