PLP: Power-Loss Protection Is an Energy Arithmetic Problem
Power-loss protection is often reduced to "there are capacitors on the board." In practice it is an energy budget that has to close. What must survive a sudden power loss is not only host-acknowledged user data, but also FTL mapping deltas, NAND pages mid-program, and journal metadata. J750/J770 are specified at a planned 18W typical, 22W maximum, 6W idle — and the worst-case flush window has to be sized against instantaneous current near the maximum, not the typical figure.
We split the budget into three segments: the response latency of power-loss detection and PCIe write quiescing, the time the controller needs to marshal dirty SRAM/DRAM state into a writable form, and NAND program time itself — where TLC programming takes the largest share of the window and is the most sensitive part of the budget. Stored energy must also be budgeted against end-of-life derating across the 5-year warranty and high-temperature operation, not against factory-fresh values. The platform is at the product-definition/EVT stage, and validating this budget means applying repeated power cuts at randomized moments across queue depths and temperature points, observing post-power-on consistency and the recovery process — not pulling the plug once to see whether it boots.
T10 DIF/DIX: Protection Information Only Pays Off End to End
On-die ECC and end-to-end protection solve different problems. ECC covers the media and the read channel; the DMA, buffering, and address-computation stages between host memory and NAND are invisible to it. T10 DIF appends 8 bytes of protection information per logical block (Guard, Application, and Reference tags), and DIX pushes the generation point out to the host application or filesystem.
Realizing the benefit requires the whole chain to agree: the drive declares supported protection types (Type 1/2/3) and metadata layout through the namespace format, while the host HBA, driver, and filesystem generate and verify under the same convention. The binding between Reference Tag and LBA matters most — it catches silent errors of the "data intact, written to the wrong address" class, which a bare CRC cannot. J750/J770 implement NVMe 1.4+, and in firmware DIF/DIX and multiple namespaces are two outlets of the same metadata management logic, so they are designed together rather than retrofitted.
Multiple Namespaces: Isolation at Tenant Granularity
The point of multiple namespaces is not "partitioning a drive" but giving each namespace its own LBA space, block size, metadata format, and protection-type configuration. In multi-tenant deployments a single 15.36TB drive can be carved for different workloads: DIF Type 1 enabled on the namespace serving a database, a different block size on the namespace holding logs, with non-overlapping address spaces so a misdirected write cannot cross the boundary.
The subtlety is accounting for write amplification and wear. Namespaces are logical isolation over a shared pool of physical blocks and a single garbage-collection engine; a tenant issuing sustained small random writes consumes shared endurance budget. The planned 3 DWPD for J770 and 1 DWPD for J750 are whole-drive figures — carving namespaces creates no additional endurance. Our approach is to expose per-namespace write volume and GC attribution through Telemetry so operators can see who is spending the budget, then apply low-latency QoS controls to contain cross-tenant interference.
NVMe-MI: The Out-of-Band Path Decides Whether Failures Are Caught Early
NVMe-MI runs out of band over SMBus/I2C, and its value is precisely that it does not depend on the data path. When a drive stops responding in band because of a firmware fault or link problem, the BMC can still read temperature, life-used percentage, and alert state — which is the difference between replacing a drive ahead of failure and recovering data after it.
Combined with Telemetry log export, online firmware update and rollback, and the TCG OPAL / Secure Boot / Sanitize set, this forms the minimum operable loop for a rack: state is observable, updates are safe, failures are reversible, and decommissioning includes trustworthy erase. On J750/J770 these are baseline features; SR-IOV and OCP-related items sit in the P1 phase. Taken together, the enterprise threshold does not rest on any single headline metric but on all four holding at once — and on each being validated case by case on the internal JH-E4U-C engineering platform rather than declared complete by writing "supported" on a datasheet.