Industry Insights

Dual-Port Failover: x2+x2 Links, Reservation Semantics and System Bring-up

著者:JH Semiconductordual-port SSD / NVMe reservations / failover

D-suffix models split the U.2/U.3 x4 link into two x2 paths. This piece covers the bandwidth-for-redundancy trade, why reservation state must be persistent, and how in-flight commands are handled at the moment of failover.

One Drive, Two Independent Paths

The D suffix on the TITAN 7 J760D and J780D, and on the Q7/Q9 J760QD and J960QD, means the PCIe x4 link on the U.2/U.3 connector is split into two x2 groups routed to separate controller domains. The cost is blunt: half the bandwidth per path. The return is that a failure in any HBA, cable or upstream controller on one path does not take the drive offline. These configurations serve dual-controller arrays and high-availability database nodes, where continuous availability outranks single-drive peak bandwidth.

Arbitration Rests on Reservations — Which Must Survive Power Loss

With two hosts seeing the same namespace, something has to prevent concurrent writes. NVMe Reservation supplies the full register, acquire, preempt and release semantics, and cluster software preempts the peer's reservation before taking over IO. What firmware has to guarantee is that reservation state is itself persistent and atomic. If reservation records are lost across a power cut, both sides can come back believing they hold write ownership — a worse outcome than plain data loss. The reservation table therefore lives on the same PLP-covered persistence path as L2P metadata.

Half-Completed Commands Are the Hard Case

Path failures usually occur with many commands in flight, leaving writes that were accepted but not completed. The surviving path must know exactly which commands crossed the persistence point and which the upper layer has to reissue. Two design constraints make that determinable: completions are posted only after data enters the power-loss-protected domain, and both ports share a single metadata view rather than maintaining separate cached copies. That shared view introduces cross-domain synchronisation overhead, which is one reason dual-port models typically trail their single-port siblings slightly on latency figures.

What to Align Before Integration

Dual port does not work simply by plugging it in. The following need to be settled at system design time:

  • Backplane topology: the two x2 groups must reach different upstream domains; routing both under one switch device defeats the redundancy.
  • Enumeration and out-of-band management: BIOS and BMC must recognise two controllers under one NVMe subsystem, and the NVMe-MI channel must stay reachable when one path fails.
  • Multipath software: failover policy, timeout thresholds and cluster arbitration must agree, so both sides do not attempt takeover simultaneously.
  • Hot-plug timing: replacing a component on one side must not produce observable IO interruption on the other.

All of these are system-level bring-up items. Passing drive-level validation does not mean the system works, which is precisely why dual-port models carry longer validation schedules than single-port ones.

キーワード
dual-port SSDNVMe reservationsfailoverhigh availability storagemultipathU.2 U.3JH Semiconductor