在 TITAN 9 系列的型號表裡，J960C 的後綴 C 代表透明壓縮。它與同系列其他 Gen5 型號共享 PLP、端到端保護、Telemetry 等功能基線，卻在資料通路上多了一段主機看不見的流水線：資料在寫入 NAND 之前先經過盤內壓縮引擎。這段流水線換來什麼、付出什麼、為什麼值得單獨立一個型號，是三筆需要分開算的賬。
壓縮做在 FTL 之下，主機才能真正無感
透明壓縮的“透明”，指主機側不需要任何改動：檔案系統、資料庫、驅動看到的仍是標準 NVMe 命名空間，邏輯塊地址與塊大小都不變。實現這一點的關鍵，是把壓縮放在 FTL 之下——主機寫入的邏輯塊先進入壓縮引擎，輸出的變長資料段再由 FTL 分配物理位置並記錄映射。也就是說，FTL 管理的物件從定長頁變成了變長段，L2P 映射除了實體地址，還要記錄每個邏輯塊壓縮後的長度與拼接邊界。讀路徑反向執行：查映射、取出壓縮段、解壓、按原始塊大小返回。整個過程對上層協議棧完全不可見。
收益的兩端：有效容量與寫放大
第一筆收益直觀：同樣的物理 NAND 可以承載超過標稱容量的邏輯資料，資料可壓縮性越好，有效容量放大越多。第二筆收益常被忽略：真正寫入 NAND 的物理資料量變少了。寫放大的分子是 NAND 實際寫入量，壓縮直接削減這個分子，垃圾回收需要搬運的有效資料也隨之減少——這意味著更低的穩態寫放大與更長的介質壽命。對寫入密集的負載，這第二筆收益甚至比容量放大更值錢。
代價：流水線延遲、吞吐匹配與容量的不確定性
壓縮不是免費的。寫路徑多了壓縮一級，讀路徑多瞭解壓一級，即便用硬體引擎實現，也要佔用延遲預算——這正是低延遲 QoS 敏感的業務需要斟酌的地方。吞吐方面，壓縮引擎的處理頻寬必須與 Gen5 前端匹配，否則介面再快也會被壓縮級卡住。更麻煩的是容量語義：有效容量隨資料內容浮動，容量規劃從一個確定數字變成一個區間，主機側需要借助 Telemetry 關注物理空間水位，避免邏輯上還有餘量、物理上已經寫滿的局面。
什麼資料壓得動，什麼壓不動
壓縮收益完全取決於資料熵。資料庫頁、日誌、文本、遙測記錄這類結構化資料通常有可觀的壓縮比；而已經壓縮過的圖片、影片、歸檔包，以及任何在主機側加密後寫入的資料，熵接近上限，盤內壓縮引擎幾乎無利可圖，還白付一遍流水線開銷。值得說明的是，盤內加密（如 TCG OPAL）發生在壓縮之後，兩者並不衝突；衝突的只是主機側先加密再寫入的部署方式。
為什麼是獨立型號，而不是全線預設
既然收益明確，為什麼不把壓縮做成全線標配？因為上面幾類代價不是所有客戶都願意付。延遲敏感的線上業務不希望資料通路多任何一級；容量必須精確核算的場景接受不了“區間容量”；負載以加密或已壓縮資料為主的使用者則純粹承擔成本而無收益。把透明壓縮收斂到 J960C 一個型號上，讓適配的負載——可壓縮資料佔比高、寫入密集、在意每 TB 成本——主動選它，其餘型號保持確定的容量語義與更短的資料通路。相比全線預設開啟再讓使用者逐一關閉，這是更誠實的產品劃分。