兩條命令，兩份不同的契約
Dataset Management 的 Deallocate 位是一個提示：主機宣告某段 LBA 不再有用，盤可以處理，也可以忽略，讀回什麼由 Identify Namespace 中的 DLFEAT 欄位決定。Write Zeroes 則是硬承諾，讀回必須是全零。這個差別直接決定韌體的實現自由度。Deallocate 可以只做映射標記；Write Zeroes 若按字面寫零頁，會白白消耗一次編程，正確做法是同樣落在映射層，把該段 LBA 指向零頁標識，將一次資料寫降級為一次後設資料更新。
有效頁計數才是回收的排程輸入
選塊靠的是每個 Block 的有效頁計數。映射標記為無效後計數立刻下調，這個 Block 在選塊佇列中的優先順序隨之上升，被選中時需要搬運的資料也真實減少。收益不來自刪除動作本身，而來自計數下調的及時性：如果韌體把 Deallocate 排到後臺慢慢消化，回收在這段窗口裡看到的仍是舊計數，仍會按舊的搬運量執行。因此我們把映射更新放在前臺命令路徑內完成，只把日誌落盤做非同步化處理。
粒度與對齊吃掉的那部分
映射表按固定粒度組織，落在粒度邊界內部的零散區間無法整條置無效，只能保留原映射。檔案系統按 4KB 釋放、盤按更大粒度映射時，這類殘留會明顯削弱效果。Dataset Management 允許一條命令攜帶多個 LBA Range，把成百上千個離散區間合併成一次提交，既降低命令開銷，也讓韌體有機會先排序合併再更新映射，把跨粒度的碎片湊成整段。
迴歸測試裡盯住的幾條曲線
在 J750/J770 的工程平臺上，我們在隨機寫達到穩態之後注入不同覆蓋率的 Deallocate，記錄三條曲線：寫放大、回收搬運位元組數，以及 4KB 隨機寫吞吐的恢復過程（J750 目標 300 KIOPS，J770 目標 600 KIOPS）。判據不是峰值有多高，而是曲線抬升的時間常數是否可預測——不可預測的恢復過程，在資料庫與虛擬化場景裡比低吞吐更難接受。產品當前處於產品定義/EVT 階段，這組用例已納入韌體迴歸。