有序移除与意外拔出走的不是同一条路
数据中心里的“拔盘”其实是两件事。有序移除由机框管理侧发起：主机先停止下发新命令，等待队列排空，通过 NVMe Shutdown Notification 让盘完成映射表落盘，最后才断开 PCIe 链路。意外拔出没有任何预告，链路层先感知到 Presence Detect 翻转，而此时控制器可能正处在一次页编程的中途。两条路径都不允许产生数据损坏，区别只在盘重新变得可用之前还要走多少步。
保持窗口真正要覆盖的是未落盘状态
掉电保护的作用窗口很短。输入电压跌到欠压阈值之后，储能必须支撑控制器把已经返回完成的写缓冲数据、以及正在更新的 L2P 页刷进 NAND。工程上的约束不是储能够不够多，而是这一瞬间还剩多少未落盘状态需要清理。固件因此把元数据日志做成增量追加的形式：运行期周期性写检查点，掉电时只补最后一段日志，而不是整表回写。J750/J770 规划中的 18 W 典型与 22 W 最大功耗同时是储能选型的输入——峰值越高，同样的保持时间需要的能量越多，这组匹配关系正是 CORE 7 在产品定义/EVT 阶段要反复取数的地方。
上电之后的时间去了哪里
异常复位后的恢复分四段：PCIe 链路重训练到 Gen4 x4、控制器自检与固件加载、L2P 从最近检查点加载并回放日志、重建 I/O 队列与命名空间上下文。前两段基本是固定开销，随容量变化的是第三段——15.36TB 档位的映射表规模是 1.92TB 的八倍，日志回放必须做成按通道分片可并行的形式，否则大容量点的就绪时间会随容量线性劣化。对上层而言，这段时间表现为盘“消失”的窗口，直接影响 Ceph OSD 或 RAID 组是否触发重平衡。
就绪时间要按分布看，不是按均值看
功能测试跑一次通过说明不了问题。可用的做法是在持续随机写负载下反复复位，每一轮上电之后做两件确认：全盘数据一致性比对，确认已返回完成的命令没有丢失；日志完整性检查，确认回放的起点与终点能够对上。记录的对象是整条就绪时间分布，因为运维排障看的是最慢的那几次。同一组用例还要在不同容量档位上重复，才能验证分片并行是否真的把容量对就绪时间的影响压平。
盘做对了不等于系统可用
U.2/U.3 背板的上下电时序、Refclk 是否独立、BIOS 对 Surprise Down 的处理方式，都会改变最终表现——同一块盘换一台整机，观察到的窗口可能完全不同。所以判断一块盘是否掉电安全，看功能清单里有没有 PLP 这一项远远不够，要看它在目标机型上把两条复位路径都跑完之后留下的那条曲线长什么样。