有序移除與意外拔出走的不是同一條路
資料中心裡的“拔盤”其實是兩件事。有序移除由機框管理側發起：主機先停止下發新命令，等待佇列排空，通過 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 這一項遠遠不夠，要看它在目標機型上把兩條復位路徑都跑完之後留下的那條曲線長什麼樣。