English 00.01.Sanitize 處理資料清除。理解它需要依序回答：清除哪些資料、使用哪一種方法、控制器目前處於什麼狀態，以及什麼證據能證明清除已完成。命令已被接受，與清除作業已完成，必須分別確認。 這篇的主軸 01決定清除範圍01-01先確認要清除的資料類別與範圍，再看控制器支援哪些清除能力。 02選擇方法與參數02-01比較區塊清除、覆寫及密碼清除的做法；命令參數必須配合所選的方法。 03區分接受、進行與完成03-01命令回覆成功不代表資料已清除完畢；持續從狀態紀錄確認進度、成功或失敗。 04理解清除後的讀取04-01媒體驗證和正常讀取的用途不同；讀回資料的意義還要結合 NVM Command Set 的規則。NVMNon-Volatile Memory，斷電後仍能保存資料的記憶體。 把主軸連起來 00.02.先選清除目標與支援的方法，再根據方法設定命令；之後由狀態紀錄判斷進度、成功或失敗。若進入媒體驗證狀態，還要分清驗證讀取與正常資料存取，並用 NVM Command Set 的規則理解清除後讀到的內容。 01 清除會涵蓋哪些資料 01.01.Sanitize scope 不是『磁碟上所有東西』。以 target、資料來源、是否可能含 user data 判斷；Boot 與診斷機制的交叉關係也從這個範圍開始。 01.02.Subsystem sanitize 與 namespace sanitize 的資料範圍不同。逐一 sanitize 全部 namespaces 不等同 subsystem sanitize，也不能因此把 subsystem GDE 設為 1。兩者都不影響 Boot Partitions 或 RPMB；含 user data 的 logs/features 則可能必須修改。namespacenamespace，主機透過 controller 存取的一份已格式化非揮發性容量。來源：Base 2.4 §8.1.27來源：NVME-BASE-2.4, Rev. 2.4, §8.1.27, 文件頁 711-712, PDF 頁 737-738 清除會涵蓋哪些資料清除對象或方法包含或排除哪些資料可據此確認的範圍Boot/RPMB不受 sanitize 影響另由自身管理機制控制Logs/features必要時修改 user data不能只檢查 namespace mediaAll namespace sanitizes只完成各 target 的工作不能因此宣告 subsystem GDECrypto Erase改 key 並處理未加密資料舊 key 副本也是重要條件 說明性範例01.03.即使所有 namespaces 都已 sanitize，CMB 等 subsystem 層級資料仍不能由這個事實證明已完成 subsystem sanitization。相反地，成功 subsystem sanitize 也不會替 Boot Partition 更新或清除開機映像。CMBController Memory...
read more
NVMe Base 2.4：Sanitize：清除範圍、方法與完成判斷
00.01.Sanitize 處理資料清除。理解它需要依序回答：清除哪些資料、使用哪一種方法、控制器目前處於什麼狀態，以及什麼證據能證明清除已完成。命令已被接受，與清除作業已完成，必須分別確認。
這篇的主軸
決定清除範圍
01-01先確認要清除的資料類別與範圍，再看控制器支援哪些清除能力。
選擇方法與參數
02-01比較區塊清除、覆寫及密碼清除的做法；命令參數必須配合所選的方法。
區分接受、進行與完成
03-01命令回覆成功不代表資料已清除完畢；持續從狀態紀錄確認進度、成功或失敗。
理解清除後的讀取
04-01媒體驗證和正常讀取的用途不同；讀回資料的意義還要結合 NVM Command Set 的規則。
- NVM
- Non-Volatile Memory，斷電後仍能保存資料的記憶體。
把主軸連起來
00.02.先選清除目標與支援的方法，再根據方法設定命令；之後由狀態紀錄判斷進度、成功或失敗。若進入媒體驗證狀態，還要分清驗證讀取與正常資料存取，並用 NVM Command Set 的規則理解清除後讀到的內容。
01 清除會涵蓋哪些資料
01.01.Sanitize scope 不是『磁碟上所有東西』。以 target、資料來源、是否可能含 user data 判斷；Boot 與診斷機制的交叉關係也從這個範圍開始。
01.02.Subsystem sanitize 與 namespace sanitize 的資料範圍不同。逐一 sanitize 全部 namespaces 不等同 subsystem sanitize，也不能因此把 subsystem GDE 設為 1。兩者都不影響 Boot Partitions 或 RPMB；含 user data 的 logs/features 則可能必須修改。
- namespace
- namespace，主機透過 controller 存取的一份已格式化非揮發性容量。
來源：Base 2.4 §8.1.27
來源：NVME-BASE-2.4, Rev. 2.4, §8.1.27, 文件頁 711-712, PDF 頁 737-738
| 清除對象或方法 | 包含或排除哪些資料 | 可據此確認的範圍 |
|---|---|---|
| Boot/RPMB | 不受 sanitize 影響 | 另由自身管理機制控制 |
| Logs/features | 必要時修改 user data | 不能只檢查 namespace media |
| All namespace sanitizes | 只完成各 target 的工作 | 不能因此宣告 subsystem GDE |
| Crypto Erase | 改 key 並處理未加密資料 | 舊 key 副本也是重要條件 |
02 清除方法、支援能力與命令參數
02.01.先把支援能力、命令要求與 Feature policy 分開。命令接受、operation 成功、符合 no-deallocate 要求是三個需要不同證據的結果。
02.02.CDW10 包含 SANACT[2:0]、AUSE[3]、OWPASS[7:4]、OIPBP[8]、NDAS[9]、EMVS[10]、PREQ[11]；CDW11 是 OVRPAT。SANACT 001b=Exit Failure Mode、010b=Block Erase、011b=Overwrite、100b=Crypto Erase、101b=Exit Media Verification；其他值保留。
- SANACT
- Sanitize Action；決定實際方法、退出 Failure 或退出 Media Verification。
- AUSE
- Allow Unrestricted Sanitize Exit；選擇失敗時是否允許不經成功重試就退出 Failure。
- EMVS
- Enter Media Verification State；成功 processing 後要求進入驗證，受方法與 capability 限制。
- NDAS
- No-Deallocate After Sanitize；命令要求，需與 SANICAP.NDI 及 NODRM 一起解讀。
- PREQ
- Purge Request；與 SPRRS 一起判定 purge 要求與回報；兩種 Sanitize 命令的 bit 位置不同。
- CDW
- CDW（Command Dword）；命令中的 32-bit 欄位單位，例如 CDW10 的 10 是欄位 index，不是 byte offset。
來源：Base 2.4 §5.2.26
來源：NVME-BASE-2.4, Rev. 2.4, §5.2.26, 文件頁 448-451, PDF 頁 474-477
| 命令與能力組合 | 控制器如何處理 | 完成或拒絕的原因 |
|---|---|---|
| NDAS=1, NDI=0 | 不得因成功 sanitize deallocate | 其他合法條件仍需符合 |
| NDAS=1, NDI=1, NODRM=0 | 命令拒絕 | Invalid Field in Command |
| NDAS=1, NDI=1, NODRM=1 | 允許處理 | 成功可回 SOS=100b |
| EMVS=1 | Subsystem 要 VERS=1 | Block/Crypto + NDAS=0 |
- NODRM
- No-Deallocate Response Mode；FID 17h bit 0，選擇受抑制 NDAS 的 error 或 warning 回應。
- NDI
- No-Deallocate Inhibited；宣告 controller 是否抑制 NDAS 的要求。
- SOS
- Sanitize Operation Status；SSTAT bits 2:0，與目前 SANS state 分開判讀。
03 背景 Sanitize 的狀態與進度
03.01.從 Figure 772 的七個 states 出發，逐一把 Figures 773–779 的 transition condition 接上。Status 描述結果，state 描述目前位置，事件描述發生的轉折。
03.02.Sanitize 在背景執行。開始 operation 後先更新 LID 81h，再完成啟動命令；Host 需用狀態 log 與事件判定後續進度。執行中的 operation 不能被 abort，並持續跨 reset/power cycle，但 verification 階段可能因指定 reset 被取消。
- Host
- 主機；執行作業系統並送出 NVMe 命令的一端。
- LID
- Log Page Identifier；指定要讀取哪一種 log page 的編號。
來源：Base 2.4 §5.2.26.1; 8.1.27.1
來源：NVME-BASE-2.4, Rev. 2.4, §5.2.26.1; 8.1.27.1, 文件頁 451,712-713, PDF 頁 477,738-739
| 作業階段 | 可以採取的後續動作 | 進度與歷史如何回報 |
|---|---|---|
| Restricted Failure | 只以 restricted 重試 | Exit Failure Mode 不可解套 |
| Unrestricted Failure | 重試或 Exit Failure Mode | 回 Idle 不會改寫失敗歷史 |
| Media Verification | Processing 已成功 | 整個 operation 仍 Sanitizing |
| Post-Verification Deallocation | SPROG 重新由 0 起算 | 失敗 FAILS=6h |
- SPROG
- Sanitize Progress；raw/65536，僅表示目前量測階段的進度。
04 操作限制與驗證讀取
04.01.把 command allowlist 與 NVM Read 特例分開判斷。Host 先辨識 target/state，再確認 PI checking 與 allocation，不能把平常 read 的處理完全套入驗證狀態。
- PI
- Protection Information；用 Guard 與 tags 檢查資料及其關聯資訊的保護欄位。
04.02.Subsystem sanitize 進行中以 Figure 144 判斷允許的 Admin 命令及 log pages；Boot Partition log 在清單內，Telemetry 07h/08h 不在。未被允許的操作受 Sanitize In Progress 限制；namespace sanitize 另依 Figures 145/146 與 target NSID 判斷。Media Verification 的 NVM Read 有特定例外。
- Admin
- Administrative，建立、設定、查詢或管理 controller 與 queue 的控制路徑。
- NSID
- Namespace Identifier，controller 用來指向 namespace 的數值 handle；identifier 不等於 namespace 物件本身。
來源：Base 2.4 §8.1.27.5; 5.1.1-5.1.2
來源：NVME-BASE-2.4, Rev. 2.4, §8.1.27.5; 5.1.1-5.1.2, 文件頁 178-181,730-732, PDF 頁 204-207,756-758
| 驗證讀取條件 | 回傳內容或狀態 | 這個結果能說明什麼 |
|---|---|---|
| PI checking requested | Invalid Field in Command | 驗證讀取不允許此組合 |
| Allocated media readable | 回實際 media data | 可忽略可讀情況的 integrity error |
| Allocated media unreadable | Unrecovered Read Error | 不可假造資料 |
| Deallocated LBA | 依 deallocated/unwritten 規則 | 不是檢查原始 media pattern 的證據 |
接著打開 Spec 看什麼
05.01.以下按概念列出閱讀位置。報告時先用上面的流程說明問題，再打開對應章節看欄位與完整條件。中文教學 HTML 另有本篇全部圖表的逐圖重點、案例與細節。
| 要說明的觀念 | Spec 閱讀位置 |
|---|---|
| 清除會涵蓋哪些資料 | Base 2.4 §8.1.27 · Base 2.4 §8.1.27.2-8.1.27.3 · NVM 1.3 §5.12 |
| 清除方法、支援能力與命令參數 | Base 2.4 §5.2.26 · Base 2.4 §8.1.27.1; 5.2.27 · Base 2.4 §5.2.30.1.16; 8.1.27.2-8.1.27.3 · Base 2.4 §5.2.26; 8.1.27.1 · Base 2.4 §5.2.26; 8.1.27.3 |
| 背景 Sanitize 的狀態與進度 | Base 2.4 §5.2.26.1; 8.1.27.1 · Base 2.4 §8.1.27.4 · Base 2.4 §8.1.27.4.6-8.1.27.4.7 · Base 2.4 §5.2.13.1.38 · Base 2.4 §5.2.13.1.38; 8.1.27.3 · Base 2.4 §8.1.27.1; 8.1.27.4 |
| 操作限制與驗證讀取 | Base 2.4 §8.1.27.5; 5.1.1-5.1.2 · Base 2.4 §8.1.27.5 · NVM 1.3 §4.1.7; 5.12 · NVM 1.3 §5.12 · NVM 1.3 §5.12.1 |
學完後想一想
1. Sanitize 命令回報 Successful Completion，是否可以立即宣告清除完成？
06.01.它表示啟動命令成功，背景 operation 可能仍在進行。後續要用相應的 Sanitize Status 判斷 operation 狀態；SPROG 與時間估計提供進度資訊，不能取代最終狀態。
來源
來源：NVME-BASE-2.4, Rev. 2.4, §5.2.26.1; 8.1.27.1, 文件頁 451,712-713, PDF 頁 477,738-739
來源：NVME-BASE-2.4, Rev. 2.4, §5.2.13.1.38, 文件頁 313-319, PDF 頁 339-345
來源：NVME-BASE-2.4, Rev. 2.4, §5.2.13.1.38; 8.1.27.3, 文件頁 314-319,718, PDF 頁 340-345,744
2. 為何不能用「讀回全零」作為所有 sanitize 方法的共同成功標準？
06.02.各方法的讀值規則不同，且 deallocation 會改用另一組規則。Block Erase、Crypto Erase、Overwrite 不能用同一預期 pattern 判斷；Media Verification state 也有自己的讀取語意。先確認 operation 狀態，再按方法與 block 狀態解釋資料。
來源
來源：NVME-BASE-2.4, Rev. 2.4, §8.1.27.2-8.1.27.3, 文件頁 714-717, PDF 頁 740-743
來源：NVME-NVM-CS-1.3, Rev. 1.3, §5.12, 文件頁 174, PDF 頁 174
來源：NVME-NVM-CS-1.3, Rev. 1.3, §5.12.1, 文件頁 174-175, PDF 頁 174-175
Comments