決定清除範圍
01-01先確認要清除的資料類別與範圍，再看控制器支援哪些清除能力。
NVMe · 規格與原理
NVMe Base 2.4：Sanitize：清除範圍、方法與完成判斷
00.01.Sanitize 處理資料清除。理解它需要依序回答：清除哪些資料、使用哪一種方法、控制器目前處於什麼狀態，以及什麼證據能證明清除已完成。命令已被接受，與清除作業已完成，必須分別確認。
這篇的主軸
選擇方法與參數
02-01比較區塊清除、覆寫及密碼清除的做法；命令參數必須配合所選的方法。
區分接受、進行與完成
03-01命令回覆成功不代表資料已清除完畢；持續從狀態紀錄確認進度、成功或失敗。
理解清除後的讀取
04-01媒體驗證和正常讀取的用途不同；讀回資料的意義還要結合 NVM Command Set 的規則。
- NVM
- Non-Volatile Memory，斷電後仍能保存資料的記憶體。
把主軸連起來
00.02.先選清除目標與支援的方法，再根據方法設定命令；之後由狀態紀錄判斷進度、成功或失敗。若進入媒體驗證狀態，還要分清驗證讀取與正常資料存取，並用 NVM Command Set 的規則理解清除後讀到的內容。
01 清除會涵蓋哪些資料
先說清楚這次清除的對象
由命令分辨作用範圍
01.01.Sanitize 與 Sanitize Namespace 的目標不同。先選定整個 subsystem 或指定 namespace，再逐類確認 user data、快取及其他儲存區是否在該操作的範圍內；不能只看它們都叫「清除」就套用相同結論。
- namespace
- namespace，主機透過 controller 存取的一份已格式化非揮發性容量。
把可用方法與資料保證連起來
01.02.SANICAP 回報支援哪些清除方法。Block Erase、Overwrite、Crypto Erase 採用不同機制；主機選擇方法前先確認支援與目標，之後才有意義討論清除完成時對原資料的保證。
區分格式改變、解除配置與清除
01.03.解除配置可能改變後續讀取行為；Format 可能改變資料格式；Sanitize 則按其範圍與方法完成資料清除。讀回全零本身無法說明先前究竟執行了哪種操作，仍要看命令、狀態與適用規則。
來源：Base 2.4 §8.1.27 · Base 2.4 §8.1.27.2-8.1.27.3 · NVM Command Set 1.3 §5.12
來源：NVME-BASE-2.4, Rev. 2.4, §8.1.27, 文件頁 711-712, PDF 頁 737-738
來源：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
把流程對回規格條件
01.05.Subsystem sanitize 與 namespace sanitize 的資料範圍不同。逐一 sanitize 全部 namespaces 不等同 subsystem sanitize，也不能因此把 subsystem GDE 設為 1。兩者都不影響 Boot Partitions 或 RPMB；含 user data 的 logs/features 則可能必須修改。
來源：Base 2.4 §8.1.27
來源：NVME-BASE-2.4, Rev. 2.4, §8.1.27, 文件頁 711-712, PDF 頁 737-738
01.06.Sanitize 涵蓋 target 的 allocated/deallocated media 與含其 user data 的快取。Subsystem sanitize 對 CMB queue 內容是否修改由實作定義，其餘 CMB 資料須處理；HMB 不受影響。PMR 必須先 disabled，subsystem sanitize 才可開始，且其資料在處理範圍內；namespace sanitize 不影響 CMB、HMB、PMR 或 PDA。
- CMB
- Controller Memory Buffer，controller 提供、可放置部分 queue 或資料結構的記憶體區域。
- HMB
- Host Memory Buffer，由 host 配置並在 enable 期間交由 controller 專用的 volatile memory ranges。
- PMR
- Persistent Memory Region，由 controller 暴露、具有持久性語意的記憶體區域。
來源：Base 2.4 §8.1.27
來源：NVME-BASE-2.4, Rev. 2.4, §8.1.27, 文件頁 711-712, PDF 頁 737-738
01.07.Block Erase 使用媒體特有 erase；Crypto Erase 改變所有相關 media encryption keys，未加密資料另以適合方法處理；Overwrite 寫入 pattern。PREQ/SPRRS 控制 purge 要求與回報；Crypto Erase 遺留舊 key 或應處理的未加密資料時須失敗。
- PREQ
- Purge Request；與 SPRRS 一起判定 purge 要求與回報；兩種 Sanitize 命令的 bit 位置不同。
來源：Base 2.4 §8.1.27.2-8.1.27.3
來源：NVME-BASE-2.4, Rev. 2.4, §8.1.27.2-8.1.27.3, 文件頁 714-717, PDF 頁 740-743
01.08.成功後 audit 讀到的值：Block Erase 為 vendor-specific，Crypto Erase 為 indeterminate，Overwrite 依 Base 的 pattern 機制。若已 deallocate，讀取另依 Deallocated or Unwritten Logical Blocks 規則；未 deallocate 且啟用 PI checking 的讀取可能發生 PI check error。
- PI
- Protection Information；用 Guard 與 tags 檢查資料及其關聯資訊的保護欄位。
來源：NVM Command Set 1.3 §5.12
來源：NVME-NVM-CS-1.3, Rev. 1.3, §5.12, 文件頁 174, PDF 頁 174
| 清除對象或方法 | 包含或排除哪些資料 | 可據此確認的範圍 |
|---|---|---|
| Boot/RPMB | 不受 sanitize 影響 | 另由自身管理機制控制 |
| Logs/features | 必要時修改 user data | 不能只檢查 namespace media |
| All namespace sanitizes | 只完成各 target 的工作 | 不能因此宣告 subsystem GDE |
| Crypto Erase | 改 key 並處理未加密資料 | 舊 key 副本也是重要條件 |
02 清除方法、支援能力與命令參數
參數必須跟著所選方法解釋
先解讀 SANACT
02.01.SANACT 決定要求執行哪一種動作。Overwrite 使用的覆寫樣式與次數，不能拿來解釋 Crypto Erase；Exit Failure Mode 等控制動作也不能當成又一次資料清除。
- SANACT
- Sanitize Action；決定實際方法、退出 Failure 或退出 Media Verification。
再解讀覆寫參數
02.02.選 Overwrite 時，OVRPAT 提供 32-bit 樣式，OWPASS 決定 pass 數，OIPBP 決定 pass 之間是否反相。OWPASS=0 有特別定義，不能套用一般數量加 1 的規則。先把每個 pass 寫下來，才能說明某個位置預期會被覆寫什麼。
清除後的處理也需要選擇
02.03.NDAS 與 NODRM 影響清除後的解除配置行為；EMVS 影響是否進入媒體驗證。它們不是清除進度。設定命令前，先決定希望清除後直接回到正常狀態，還是需要依支援能力進行驗證。
- NODRM
- No-Deallocate Response Mode；FID 17h bit 0，選擇受抑制 NDAS 的 error 或 warning 回應。
- EMVS
- Enter Media Verification State；成功 processing 後要求進入驗證，受方法與 capability 限制。
- NDAS
- No-Deallocate After Sanitize；命令要求，需與 SANICAP.NDI 及 NODRM 一起解讀。
收到成功回覆後開始追蹤作業
02.04.啟動命令成功只確立控制器接受了要求。接著讀 LID 81h，確認正在處理、成功、失敗或進入後續狀態；命令的 CQE 與背景作業的結果是兩個觀察點。
- CQE
- Completion Queue Entry，CQ 中的一筆完成結果資料結構。
- LID
- Log Page Identifier；指定要讀取哪一種 log page 的編號。
來源：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
來源：NVME-BASE-2.4, Rev. 2.4, §5.2.26, 文件頁 448-451, PDF 頁 474-477
來源：NVME-BASE-2.4, Rev. 2.4, §8.1.27.1; 5.2.27, 文件頁 713,453, PDF 頁 739,479
來源：NVME-BASE-2.4, Rev. 2.4, §5.2.30.1.16; 8.1.27.2-8.1.27.3, 文件頁 477-478,715-719, PDF 頁 503-504,741-745
來源：NVME-BASE-2.4, Rev. 2.4, §5.2.26, 文件頁 449, PDF 頁 475
來源：NVME-BASE-2.4, Rev. 2.4, §5.2.26; 8.1.27.1, 文件頁 449-451,712-714, PDF 頁 475-477,738-740
來源：NVME-BASE-2.4, Rev. 2.4, §5.2.26; 8.1.27.3, 文件頁 451,717, PDF 頁 477,743
把流程對回規格條件
02.06.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；其他值保留。
- AUSE
- Allow Unrestricted Sanitize Exit；選擇失敗時是否允許不經成功重試就退出 Failure。
- 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
02.07.Namespace Sanitize 的命令格式如下：SANACT 只允許 001b、100b、101b；AUSE 在 bit 3、PREQ 在 bit 4、EMVS 在 bit 10。它沒有 Overwrite/NDAS 欄位，不可直接複製 subsystem Sanitize 的 CDW10。
來源：Base 2.4 §8.1.27.1; 5.2.27
來源：NVME-BASE-2.4, Rev. 2.4, §8.1.27.1; 5.2.27, 文件頁 713,453, PDF 頁 739,479
02.08.NDAS 是本次命令的保留配置要求；NDI 表示 controller 是否抑制它。NDAS=1 且 NDI=1 時，FID 17h 的 NODRM=0 使命令以 Invalid Field in Command 拒絕，NODRM=1 可接受並在成功後以 SOS=100b 回報 unexpected deallocation。NODMMAS=10b 則描述適用時的額外 media modification。
- controller
- controller，實作 NVMe 介面、取走 command 並回報 completion 的控制實體。
- FID
- Feature Identifier；指定要讀取或設定哪一項 Feature 的編號。
- NDI
- No-Deallocate Inhibited；宣告 controller 是否抑制 NDAS 的要求。
- SOS
- Sanitize Operation Status；SSTAT bits 2:0，與目前 SANS state 分開判讀。
來源：Base 2.4 §5.2.30.1.16; 8.1.27.2-8.1.27.3
來源：NVME-BASE-2.4, Rev. 2.4, §5.2.30.1.16; 8.1.27.2-8.1.27.3, 文件頁 477-478,715-719, PDF 頁 503-504,741-745
02.09.Subsystem sanitize 要求 EMVS=1 時，需要 VERS=1、SANACT 為 Block Erase 或 Crypto Erase，且 NDAS=0；Overwrite 或 NDAS=1 的組合以 Invalid Field in Command 拒絕。SANACT=101b 只可在 Media Verification state 使用，並啟動後續 deallocation 而非新的 sanitize。
來源：Base 2.4 §5.2.26
來源：NVME-BASE-2.4, Rev. 2.4, §5.2.26, 文件頁 449, PDF 頁 475
02.10.PMR enabled、namespace write protection、controller suspended 或 pending firmware activation/reset 都可能阻止 subsystem sanitize。若啟動命令不是 Successful Completion，就不開始該 operation、不改 target 的 Sanitize Status，也不改 user data；已能預知的 operation 失敗則宜由後續 log 回報。
來源：Base 2.4 §5.2.26; 8.1.27.1
來源：NVME-BASE-2.4, Rev. 2.4, §5.2.26; 8.1.27.1, 文件頁 449-451,712-714, PDF 頁 475-477,738-740
02.11.OWPASS=0h 表示 16 passes。OIPBP=0 時 user data 使用 OVRPAT、PI bytes 為 FFh。OIPBP=1 且總次數為偶數時第一輪使用反相 pattern、PI=00h；奇數時第一輪使用原 pattern、PI=FFh，其後逐輪反相。
來源：Base 2.4 §5.2.26; 8.1.27.3
來源：NVME-BASE-2.4, Rev. 2.4, §5.2.26; 8.1.27.3, 文件頁 451,717, PDF 頁 477,743
| 命令與能力組合 | 控制器如何處理 | 完成或拒絕的原因 |
|---|---|---|
| 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 |
03 背景 Sanitize 的狀態與進度
用狀態決定進度值的意義
先讀作業狀態
03.01.LID 81h 的 SSTAT 告訴主機清除作業的結果狀態；SPROG 提供進度，但必須在其適用條件下使用。不要先把 SPROG 換成百分比，再假定控制器仍在執行。
- SPROG
- Sanitize Progress；raw/65536，僅表示目前量測階段的進度。
讓紀錄對回啟動要求
03.02.SCDW10 保存相關命令設定，可協助辨認狀態對應的操作。若涉及 namespace 作業，再用 STNSID 確認目標；MNSOIP 說明允許同時執行的 namespace 作業數上限，並不回報目前作業數；不能把一份 subsystem 層級紀錄直接解釋成任意 namespace 的獨立完成證明。
失敗時先分辨目前允許的操作
03.03.Restricted 與 Unrestricted 的差別會影響控制器在處理或失敗狀態下接受哪些命令。狀態圖的箭頭必須同時讀起點、觸發動作與條件；同樣是重新提出清除要求，適用條件可能因目前狀態而不同。
驗證與驗證後解除配置另有階段
03.04.進入 Media Verification 不代表已恢復正常 I/O。離開驗證後是否還要進行解除配置，取決於對應選項與條件。沿著狀態圖走到終點，再決定能不能對外宣告整個要求的流程完成。
- I/O
- Input/Output，對 namespace 執行資料輸入與輸出的操作類別。
來源：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
來源：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, §8.1.27.4, 文件頁 719-730, PDF 頁 745-756
來源：NVME-BASE-2.4, Rev. 2.4, §8.1.27.4.6-8.1.27.4.7, 文件頁 727-730, PDF 頁 753-756
來源：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
來源：NVME-BASE-2.4, Rev. 2.4, §8.1.27.1; 8.1.27.4, 文件頁 712-713,720, PDF 頁 738-739,746
把流程對回規格條件
03.06.Sanitize 在背景執行。開始 operation 後先更新 LID 81h，再完成啟動命令；Host 需用狀態 log 與事件判定後續進度。執行中的 operation 不能被 abort，並持續跨 reset/power cycle，但 verification 階段可能因指定 reset 被取消。
- Host
- 主機；執行作業系統並送出 NVMe 命令的一端。
來源：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
03.07.每個支援的 target 有一份狀態機。AUSE=0/1 分別進入 Restricted/Unrestricted Processing；失敗落入對應 Failure。Restricted Failure 必須以 restricted sanitize 重試；Unrestricted Failure 可重試或 Exit Failure Mode 回 Idle。Idle 因而不必然表示最後一次 sanitize 成功。
來源：Base 2.4 §8.1.27.4
來源：NVME-BASE-2.4, Rev. 2.4, §8.1.27.4, 文件頁 719-730, PDF 頁 745-756
03.08.Processing 成功且 EMVS 要求未被取消時進入 Media Verification。Exit Media Verification、適用 reset 或阻止驗證的 composition change 使 target 進入 Post-Verification Deallocation；成功才回 Idle，失敗依原 AUSE 回 Restricted/Unrestricted Failure，FAILS=6h。
來源：Base 2.4 §8.1.27.4.6-8.1.27.4.7
來源：NVME-BASE-2.4, Rev. 2.4, §8.1.27.4.6-8.1.27.4.7, 文件頁 727-730, PDF 頁 753-756
03.09.LID 81h 的 NSID=0h 或 FFFFFFFFh 指 subsystem，allocated NSID 指 namespace。SSTAT 含 SOS、OPC、GDE、MVCNCLD、NDE、PRGD；SSI 含 SANS/FAILS；SCDW10 保存啟動參數。MNSOIP 回報並行 namespace operations 上限，STNSID 識別 namespace target。Log 跨 power cycles/resets 保留。
- MVCNCLD
- Media Verification Canceled；記錄要求的驗證被取消，會影響 processing 後的轉移。
- NSID
- Namespace Identifier，controller 用來指向 namespace 的數值 handle；identifier 不等於 namespace 物件本身。
來源：Base 2.4 §5.2.13.1.38
來源：NVME-BASE-2.4, Rev. 2.4, §5.2.13.1.38, 文件頁 313-319, PDF 頁 339-345
03.10.SPROG 的比例是 raw/65536，分別表示 Processing 或 Post-Verification Deallocation 的進度，進入這些階段時重設為 0。Media Verification 時可為 FFFFh 而 SOS 仍是 Sanitizing；不能只看 SPROG 判斷完成。時間估計依方法與額外 media modification 分開，FFFFFFFFh 表示未回報。
來源：Base 2.4 §5.2.13.1.38; 8.1.27.3
來源：NVME-BASE-2.4, Rev. 2.4, §5.2.13.1.38; 8.1.27.3, 文件頁 314-319,718, PDF 頁 340-345,744
03.11.Sanitize AER 使用 AET=110b、LID=81h，AEI=01h/02h/03h 分別表示 Completed、Completed With Unexpected Deallocation、Entered Media Verification。DW1 的 EVNTSP 為 subsystem 的 0h 或 target NSID。事件要與 log 一起判讀，Completed 不自動代表成功。
- AER
- Advanced Error Reporting，PCIe 用來分類、遮罩與記錄 link／transaction error 的 capability。
來源：Base 2.4 §8.1.27.1; 8.1.27.4
來源：NVME-BASE-2.4, Rev. 2.4, §8.1.27.1; 8.1.27.4, 文件頁 712-713,720, PDF 頁 738-739,746
| 作業階段 | 可以採取的後續動作 | 進度與歷史如何回報 |
|---|---|---|
| Restricted Failure | 只以 restricted 重試 | Exit Failure Mode 不可解套 |
| Unrestricted Failure | 重試或 Exit Failure Mode | 回 Idle 不會改寫失敗歷史 |
| Media Verification | Processing 已成功 | 整個 operation 仍 Sanitizing |
| Post-Verification Deallocation | SPROG 重新由 0 起算 | 失敗 FAILS=6h |
04 操作限制與驗證讀取
清除後讀回來的資料可以證明什麼
先確定讀取所處階段
04.01.在媒體驗證狀態執行的讀取，與恢復正常狀態後的 Read 有不同使用條件。先確認控制器狀態及可接受的命令，再讀資料內容。
把方法、配置狀態與格式連起來
04.02.Block Erase、Crypto Erase、Overwrite 後的讀取規則，還要結合 logical block 是否被解除配置及所選格式。某次讀取回全零，不會單獨證明使用了哪一種清除方法。
- logical block
- 邏輯區塊；namespace 可定址的基本單位，其資料大小由使用中的格式決定。
資料保護欄位也要配合解讀
04.03.若格式含 PI，PRACT、PRCHK 與 Storage Tag 檢查選擇會影響此次讀取和檢查。先依 NVM Command Set 的清除後規則判斷資料與 metadata，再解釋檢查結果；不能用清除前的 tag 假設去替清除後資料下結論。
- metadata
- 隨 logical block 儲存的附加資料，可包含資料保護資訊，也可有其他用途。
- PRCHK
- Protection Information Check；三個 bits 分別要求 guard、application tag、reference tag 檢查；驗證讀取設 000b。
來源：Base 2.4 §8.1.27.5; 5.1.1-5.1.2 · Base 2.4 §8.1.27.5 · NVM Command Set 1.3 §4.1.7; 5.12 · NVM Command Set 1.3 §5.12 · NVM Command Set 1.3 §5.12.1
來源：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
來源：NVME-BASE-2.4, Rev. 2.4, §8.1.27.5, 文件頁 730-732, PDF 頁 756-758
來源：NVME-NVM-CS-1.3, Rev. 1.3, §4.1.7; 5.12, 文件頁 113,173-175, PDF 頁 113,173-175
來源：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
把流程對回規格條件
04.05.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 的控制路徑。
來源：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
04.06.Sanitize 開始時 controllers 更新 target log 並暫停 autonomous power state management。依 target 中止受影響 I/O/self-test、釋放相關 streams；進行中不得 activation 新 firmware。Subsystem operation 也阻止 PMR enable 與 PDA access。
來源：Base 2.4 §8.1.27.5
來源：NVME-BASE-2.4, Rev. 2.4, §8.1.27.5, 文件頁 730-732, PDF 頁 756-758
04.07.NVM 4.1.7 沿用 Base 的 Sanitize command；5.12 補充允許的 Admin 行為、sanitize 後的資料值與 Media Verification Read。Error Information 的 LBA 要回傳 0，其他含 user data 的欄位仍依 Base 處理。
來源：NVM Command Set 1.3 §4.1.7; 5.12
來源：NVME-NVM-CS-1.3, Rev. 1.3, §4.1.7; 5.12, 文件頁 113,173-175, PDF 頁 113,173-175
04.08.Media Verification Read 不要求 PI checking，即 PRCHK=000b 且 STC=0。Allocated media 能讀時回傳實際資料並忽略可讀情況下的 integrity errors，未被其他錯誤中止就以 Successful Media Verification Read 完成；不能讀取 allocated media 時回 Unrecovered Read Error。指定 PI checking 則回 Invalid Field in Command。
- STC
- Storage Tag Check；本報告指 NVM Read 的 storage tag 檢查，驗證讀取設 0。
來源：NVM Command Set 1.3 §5.12.1
來源：NVME-NVM-CS-1.3, Rev. 1.3, §5.12.1, 文件頁 174-175, PDF 頁 174-175
| 驗證讀取條件 | 回傳內容或狀態 | 這個結果能說明什麼 |
|---|---|---|
| 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 的證據 |
05 讀懂本篇的規格圖表
05.01.以下依概念整理規格中的圖表。每組先說明讀取順序與要判斷的問題，接著列出各圖的欄位或行為說明。可以由正文的連結跳到對應組別，也可以用這一節檢查自己能否把欄位連回完整操作。
圖表組 01 · 清除會涵蓋哪些資料 · 12 張圖表
05.02.範圍圖先分 subsystem、namespace 及明確排除區域，再把清除方法放到正確對象上。GDE 等整體狀態的判斷必須使用其定義的範圍，不能由較小範圍的成功結果直接推論。
回到本節的解釋與範例從操作與狀態選出正確的規則列
05.03.先辨認命令、控制器類型及目前狀態，再讀支援或限制。狀態碼還要配 SCT，不能只看 SC 的數字。
- SCT
- Status Code Type；指定完成狀態碼所屬類別，需與 SC 一起解讀。
- SC
- Status Code；指定所選 SCT 類別中的完成結果。
| 一起判讀的欄位或標示 | 如何共同決定操作或結果 | 帶入情境後怎麼讀 |
|---|---|---|
| Opcode／NSID／資料方向 | Opcode 選操作，NSID 選對象，方向決定主機提供或接收什麼。 | Copy 的主機傳入資料是描述子清單，並非整份來源資料。 |
| SCT／SC | 狀態類別決定使用哪份狀態表；同一類別內再判斷原因。 | LBA Out of Range 針對位址範圍，Capacity Exceeded 針對配置容量，不應混為一談。 |
| 支援標記／適用註腳 | 需要结合可選能力、控制器種類與目前操作的限制。 | 控制器平常支援 Read，不代表清除的每一種受限狀態都允許同樣行為。 |
| ANA／Reservation type／Holder／Registrant | 路徑狀態與主機的存取資格分別影響操作；逐項配合命令種類判斷。 | 同一 namespace 對兩個主機可有不同存取資格，不能只用 NSID 相同推論结果相同。 |
- ANA
- Asymmetric Namespace Access；描述同一 namespace 經不同 controllers 存取時的路徑狀態。
來源：NVM Command Set 1.3 §5.12
來源：NVME-NVM-CS-1.3, Rev. 1.3, §5.12, Figure 200, 文件頁 173, PDF 頁 173
NVM Figure 200 · Sanitize Operations - Admin Commands Allowed
一句話重點
NVM200-1Sanitize 期間仍可執行哪些 Admin 命令，要按作業情境查表。
來源：NVM Command Set 1.3 §5.12
來源：NVME-NVM-CS-1.3, Rev. 1.3, §5.12, Figure 200, 文件頁 173, PDF 頁 173
用例子讀懂
NVM200-2清除進行中想讀 Get Log Page，需看這張表及該 log 的條件；不能以「正在清除」推論所有管理命令都停止。
清除後讀值要結合所用方法與配置狀態
05.04.先確認清除方法及操作完成，再依是否解除配置、資料格式與命令選项解釋後續讀取。
| 一起判讀的欄位或標示 | 如何共同決定操作或結果 | 帶入情境後怎麼讀 |
|---|---|---|
| Block Erase／Crypto Erase／Overwrite | 各方法對 user data 的處理不同，完成保證及後續讀值按相應列判斷。 | Overwrite 的樣式與 Block Erase 的讀值不可直接交換解釋。 |
| Data／Metadata／PI／解除配置 | 資料與保護資訊可能有不同處理條件；解除配置也會影響讀取行為。 | 讀到零值只是一次讀取結果，還需要狀態紀錄證明清除作業已完成。 |
來源：NVM Command Set 1.3 §5.12
來源：NVME-NVM-CS-1.3, Rev. 1.3, §5.12, Figure 201, 文件頁 174, PDF 頁 174
NVM Figure 201 · Sanitize Operation Types - User Data Values
一句話重點
NVM201-1清除方法不同，清除後可觀察到的使用者資料值也不同。
來源：NVM Command Set 1.3 §5.12
來源：NVME-NVM-CS-1.3, Rev. 1.3, §5.12, Figure 201, 文件頁 174, PDF 頁 174
用例子讀懂
NVM201-2Overwrite 的內容與 pattern 及輪數有關；Crypto Erase 不應被口頭簡化成「全部 bytes 寫零」。
沿資料所在位置，比較兩種清除目標
05.05.先選 subsystem 或單一 namespace，再沿表的資料類別逐列比較。對每個 namespace 都執行清除，仍不等同執行一次 subsystem 清除。
| 一起判讀的欄位或標示 | 如何共同決定操作或結果 | 帶入情境後怎麼讀 |
|---|---|---|
| 已配置與已解除配置的媒體 | subsystem 涵蓋整體相應媒體；namespace 涵蓋配置給目標使用、以及先前配置給它後又解除配置的媒體。 | 只看目前 LBA 對應的配置不足以理解範圍，先前已解除配置的資料也需要依此規則處理。 |
| volatile／non-volatile caches／其他內部 buffers | 兩種目標都要處理對應 user data；namespace 範圍依曾對該目標讀寫的資料限定。 | 資料暫存在內部 buffer，不會因尚未寫入最終媒體就自動落在清除範圍之外。 |
| 不可寫媒體／不可改寫的 subsystem 資訊 | 含 user data 但不能寫入的媒體仍需達到不可取回要求；序號等不可寫 subsystem 資訊則不受影響。 | 「不可寫」不是所有資料的免除條件：含舊 user data 的區域與裝置序號是兩個不同類別。 |
| Features／Log pages | 依功能及目標需要修改相關資訊，避免從它們恢復 user data；namespace 的 Purge Namespace Metadata 與 Namespace Admin Label 另有指定處理。 | 不能只清除一般 Read 的資料區，卻忽略可能留在 log 或功能值裡的 user data。 |
| Boot／HMB／Firmware／security credentials／RPMB | 這些列不因 Sanitize 自動變成已清除；規格對 Boot、HMB、firmware、認證資訊等列有無影響的界線。 | subsystem Sanitize 成功不表示 Boot 映像被抹除，不能用它代替 Boot 更新。 |
| CMB／PMR／NVMe-MI PDA | namespace 清除不影響這三類；subsystem 清除修改 CMB 中非佇列資料，佇列是否修改由實作決定，PMR 與 PDA 資料另在相應範圍內。 | PMR 必須先停用才允許開始 subsystem Sanitize；逐一清除 namespaces 不能替代這項 PMR 資料處理。 |
- NVMe
- Non-Volatile Memory Express，主機與非揮發性記憶體子系統之間的介面規範家族。
來源：Base 2.4 §8.1.27
來源：NVME-BASE-2.4, Rev. 2.4, §8.1.27, Figure 770, 文件頁 711-712, PDF 頁 737-738
Base Figure 770 · Sanitization Operation Scope Based on Sanitize Operation
一句話重點
Base770-1清除範圍隨 subsystem 或 namespace 目標而不同。
來源：Base 2.4 §8.1.27
來源：NVME-BASE-2.4, Rev. 2.4, §8.1.27, Figure 770, 文件頁 711-712, PDF 頁 737-738
用例子讀懂
Base770-2清除一個 namespace，不能推論其他 namespace、Boot Partition 或其他列出的區域全部同時被清除；按目標欄逐項看。
從第一遍樣式推到最後一遍與 PI
05.06.這張表同時使用反相選項、總遍數的奇偶、目前是第幾遍，以及資料是否為 PI。第一遍並非所有情況都使用命令給的樣式。
| 一起判讀的欄位或標示 | 如何共同決定操作或結果 | 帶入情境後怎麼讀 |
|---|---|---|
| OIPBP=0 | 每一遍的 user data 都使用指定 Overwrite Pattern，PI 的每個 byte 設為 FFh。 | OVRPAT=12345678h 時，增加 pass 數不會在相鄰 passes 之間自動反相。 |
| OIPBP=1／總遍數為偶數 | 第一遍 user data 使用指定樣式的反相，PI bytes 從 00h 開始；後續每遍將前一遍各 bit 反相。 | OVRPAT=00000000h、2 passes：user data 為 FFFFFFFFh→00000000h；PI byte 為 00h→FFh。 |
| OIPBP=1／總遍數為奇數 | 第一遍 user data 使用指定樣式，PI bytes 從 FFh 開始；後續同樣逐遍反相。 | OVRPAT=00000000h、3 passes：user data 為 00000000h→FFFFFFFFh→00000000h；PI byte 為 FFh→00h→FFh。 |
| 最後一遍／metadata 中的 PI | 奇偶規則讓最後一遍回到指定 user-data 樣式，PI bytes 為 FFh；非 PI 的 user-data 部分按另一欄處理。 | 不要把 user-data 的 32-bit OVRPAT 直接套到所有 PI bytes，兩欄的起始規則不同。 |
來源：Base 2.4 §8.1.27.3
來源：NVME-BASE-2.4, Rev. 2.4, §8.1.27.3, Figure 771, 文件頁 717, PDF 頁 743
Base Figure 771 · Sanitize Operations - Overwrite Mechanism
一句話重點
Base771-1Overwrite 每輪的 pattern 取決於初值、反相設定與輪數。
來源：Base 2.4 §8.1.27.3
來源：NVME-BASE-2.4, Rev. 2.4, §8.1.27.3, Figure 771, 文件頁 717, PDF 頁 743
用例子讀懂
Base771-2初值 A5A5A5A5h、相應反相條件成立時，反相值為 5A5A5A5Ah；依輪次追圖，不能只記最後一次寫入的名稱。
查能力、讀取值與寫入值的區別
05.07.FID 指功能，Get 的 SEL 指要查哪一種資訊，Set 的 SV 指是否要求保存。支援能力回覆的 bits 與功能值是不同結構。
- SEL
- Select，Get Features 用來選 current、default、saved 或 supported-capabilities view 的欄位。
- SV
- Save，Set Features 要求 controller 同時保存所設定 value 的 bit。
| 一起判讀的欄位或標示 | 如何共同決定操作或結果 | 帶入情境後怎麼讀 |
|---|---|---|
| FID／UIDX／DPTR | FID 選功能，必要時 UIDX 協助選 UUID，DPTR 傳輸該功能所需的資料結構。 | 不是每個 Feature 都只靠 CQE DW0 回覆；有 buffer 的功能還需讀其資料格式。 |
| SEL=000b／001b／010b／011b | 分別要求目前值、預設值、保存值、支援能力。 | 要確認裝置現在採用什麼值，應讀目前值；保存值不等於正在使用的值。 |
| CHANG／NSSPEC／SVBL → SV | 能力分別指出可變更、是否與 namespace 有關、可否保存；SV 是主機的保存要求。 | SVBL=0 時提出保存要求可能被拒絕；Set 成功也不能一律推論跨 power cycle 保留。 |
- NSSPEC
- Namespace Specific，指出 Feature 是否具有 per-namespace scope 的 capability bit。
- CHANG
- Changeable，指出 Feature value 是否可由 Set Features 變更的 capability bit。
- DPTR
- Data Pointer，SQE 中指出 command data buffer 的欄位。
- SVBL
- Saveable，supported-capabilities result 中指出 Feature 是否可保存的 bit。
- UIDX
- UUID Index，指向 UUID List 位置的 index；0 表示未指定 UUID。
- UUID
- Universally Unique Identifier，128-bit identifier；其實際關聯範圍仍由使用它的資料結構決定。
來源：Base 2.4 §5.2.12.2
來源：NVME-BASE-2.4, Rev. 2.4, §5.2.12.2, Figure 201, 文件頁 212, PDF 頁 238
Base Figure 201 · Completion Queue Entry Dword 0 when Select is set to 11b
一句話重點
Base201-1Supported Capabilities 回覆把可修改、namespace 範圍與可保存能力分開。
來源：Base 2.4 §5.2.12.2
來源：NVME-BASE-2.4, Rev. 2.4, §5.2.12.2, Figure 201, 文件頁 212, PDF 頁 238
用例子讀懂
Base201-2CHANG 表示可修改，SVBL 表示可保存；支援其中一項，不代表另一項也成立。
同一筆 Get Log Page 的目標、範圍與資料位置
05.08.讀 log 先選 LID 與命令集，再解讀該 log 的 LSP／LSI；NUMD 決定本次量，LPO 決定本次起點，DPTR 決定主機接收位置。
- NUMD
- Number of Dwords，0's-based transfer dword count；實際 bytes = (NUMD + 1) × 4。
- LSI
- Log Specific Identifier，意義由所選 log page 定義的 identifier。
- LSP
- Log Specific Field，意義由所選 log page 定義的 command selector。
| 一起判讀的欄位或標示 | 如何共同決定操作或結果 | 帶入情境後怎麼讀 |
|---|---|---|
| LID／CSI／LSP／LSI | LID 與 CSI 選紀錄種類，LSP、LSI 的含義由所選 log 定義。 | LSP 在 Boot 中可含 BPID，在 Telemetry 中有建立 capture 的控制位元，不能跨 log 照搬。 |
| NUMDU／NUMDL | 先合成 NUMD=(NUMDU<<16)|NUMDL，再計算 (NUMD+1)×4 bytes。 | 512 bytes 對應 NUMD=127；高低部分不能各自加 1。 |
| LPOU／LPOL／OT | 高低欄位組成 64-bit offset；OT 決定按 byte 位移或項目索引解讀。 | byte-offset 模式下，從 512-byte 表頭後開始讀資料要保留起點差異；index 模式不能直接使用同一個 byte 數。 |
| DPTR／RAE | DPTR 給接收記憶體，RAE 控制相關事件的保留行為。 | 分段讀取先準備每段 buffer，再在恰當時機確認事件，避免中途改變可取得的紀錄。 |
| LSUPP／LID Specific Parameter | Supported Log Pages 回報實際支援及 log 專屬能力。 | 規格列有某個 LID，不代表此裝置一定實作；先查支援再使用進階選項。 |
- offset
- offset；從指定起點算出的位移。它回答「離起點多遠」，不等於 index。
- NUMDL
- Number of Dwords Lower，Get Log Page 的 NUMD 低 16 bits。
- NUMDU
- Number of Dwords Upper，Get Log Page 的 NUMD 高 16 bits。
- index
- index；用來選取清單中的項目或格式。它回答「選哪一項」，不是「離起點多遠」。
- BPID
- Boot Partition Identifier；選取 0 或 1，與目前 active partition 分開。
- LPOL
- Log Page Offset Lower，Get Log Page byte offset 的低 32 bits。
- LPOU
- Log Page Offset Upper，Get Log Page byte offset 的高 32 bits。
- CSI
- I/O Command Set Identifier；選擇 I/O 命令集，NVM Command Set 使用 00h。
- RAE
- Retain Asynchronous Event；Telemetry 收集中用 1 保留通知狀態，完成後用 0 acknowledgement。
來源：Base 2.4 §5.2.13
來源：NVME-BASE-2.4, Rev. 2.4, §5.2.13, Figure 203, 文件頁 213, PDF 頁 239
來源：NVME-BASE-2.4, Rev. 2.4, §5.2.13, Figure 204, 文件頁 213, PDF 頁 239
來源：NVME-BASE-2.4, Rev. 2.4, §5.2.13, Figure 205, 文件頁 214, PDF 頁 240
來源：NVME-BASE-2.4, Rev. 2.4, §5.2.13, Figure 206, 文件頁 214, PDF 頁 240
來源：NVME-BASE-2.4, Rev. 2.4, §5.2.13, Figure 207, 文件頁 214, PDF 頁 240
來源：NVME-BASE-2.4, Rev. 2.4, §5.2.13, Figure 208, 文件頁 214-215, PDF 頁 240-241
來源：NVME-BASE-2.4, Rev. 2.4, §5.2.13, Figure 209, 文件頁 215-216, PDF 頁 241-242
Base Figure 203 · Get Log Page - Data Pointer
一句話重點
Base203-1Get Log Page 的 DPTR 指向主機接收 log 資料的空間。
來源：Base 2.4 §5.2.13
來源：NVME-BASE-2.4, Rev. 2.4, §5.2.13, Figure 203, 文件頁 213, PDF 頁 239
用例子讀懂
Base203-2同樣是 512-byte buffer，LID 不同會得到不同結構；DPTR 只提供位置，不會決定 log 類型。
Base Figure 204 · Get Log Page - Command Dword 10
一句話重點
Base204-1Get Log Page 的 CDW10 選擇 log、低位長度及相關控制參數。
來源：Base 2.4 §5.2.13
來源：NVME-BASE-2.4, Rev. 2.4, §5.2.13, Figure 204, 文件頁 213, PDF 頁 239
用例子讀懂
Base204-2讀取 512 bytes 共 128 Dwords，長度原始值為 127；同時填正確 LID，才能知道回來的是哪一份紀錄。
Base Figure 205 · Get Log Page - Command Dword 11
一句話重點
Base205-1CDW11 提供長度高位與 log 特定識別資訊。
來源：Base 2.4 §5.2.13
來源：NVME-BASE-2.4, Rev. 2.4, §5.2.13, Figure 205, 文件頁 214, PDF 頁 240
用例子讀懂
Base205-2NUMDU 非零時總長度需與 NUMDL 合併後再加 1；不能把兩個長度欄位各加 1 再相加。
Base Figure 206 · Get Log Page - Command Dword 12
一句話重點
Base206-1LPOL 是 log offset 的低 32 bits，單位還要看 offset 模式。
來源：Base 2.4 §5.2.13
來源：NVME-BASE-2.4, Rev. 2.4, §5.2.13, Figure 206, 文件頁 214, PDF 頁 240
用例子讀懂
Base206-2byte-offset 模式下讀下一段 512 bytes，LPOL 設 512；index-offset 模式則以項目索引解釋，數字 512 不再表示相同位置。
- index-offset
- index-offset 對比；index 選取項目，offset 計算位置。例如從 0 起算的 Format Index=2 選第 3 個格式，而 OFST=256 表示從 image 起點位移 256 個 Dwords。
Base Figure 207 · Get Log Page - Command Dword 13
一句話重點
Base207-1LPOU 補齊較大 log offset 的高 32 bits。
來源：Base 2.4 §5.2.13
來源：NVME-BASE-2.4, Rev. 2.4, §5.2.13, Figure 207, 文件頁 214, PDF 頁 240
用例子讀懂
Base207-2完整 offset＝00000001_00000000h 時，LPOU＝1、LPOL＝0；只讀 LPOL 會誤以為從開頭開始。
Base Figure 208 · Get Log Page - Command Dword 14
一句話重點
Base208-1CDW14 的 CSI、OT、UIDX 決定命令集、offset 模式與相關選擇。
來源：Base 2.4 §5.2.13
來源：NVME-BASE-2.4, Rev. 2.4, §5.2.13, Figure 208, 文件頁 214-215, PDF 頁 240-241
用例子讀懂
Base208-2相同 LPOL＝4，在 byte-offset 與 index-offset 下表示不同事物；先看 OT 才能正確解讀位置。
Base Figure 209 · Get Log Page - Log Page Identifiers
一句話重點
Base209-1LID 清單把紀錄編號與其命令集、範圍連在一起。
來源：Base 2.4 §5.2.13
來源：NVME-BASE-2.4, Rev. 2.4, §5.2.13, Figure 209, 文件頁 215-216, PDF 頁 241-242
用例子讀懂
Base209-2先依本篇所需的紀錄選取清單中的對應列，再看 CSI 與作用範圍；編號只選紀錄種類，完整欄位排列仍到該 log 的結構表閱讀。
圖表組 02 · 清除方法、支援能力與命令參數 · 6 張圖表
05.09.先讀 Sanitize 支援方法，再依 SANACT 選分支。條件表一次固定其他欄位，只改 NDAS、NDI 或 NODRM 中一項，觀察結果；EMVS 的支援與方法限制另行核對。
回到本節的解釋與範例每個選項會在哪一階段改變結果
05.10.SANACT 先決定動作，再判斷其他位元是否適用。Sanitize Namespace 的欄位集合較小，不能複製整份 subsystem 命令參數而不檢查。
| 一起判讀的欄位或標示 | 如何共同決定操作或結果 | 帶入情境後怎麼讀 |
|---|---|---|
| SANACT／AUSE | SANACT 選方法或控制動作；AUSE 決定失敗後的受限處理路徑。 | 同樣的 Block Erase，AUSE 選擇不同會走向不同失敗狀態；它不改變方法本身。 |
| OWPASS bits 7:4／OIPBP／OVRPAT | OWPASS=0 表示 16 passes，其餘非零編碼直接表示 pass 數；OIPBP=1 還要依總 pass 數的奇偶決定第一遍樣式。 | 要求 2 passes、樣式 00000000h、反相=1：第一遍 FFFFFFFFh，第二遍 00000000h，最後一遍回到指定樣式。 |
| PREQ／SPRRS | PREQ 提出 Purge 要求；SPRRS=0 時該位元為保留位元。 | SPRRS=1 且 PREQ=1，若未達規定的 Purge 保證，作業應失敗；不能只靠讀回零來替代這項判斷。 |
| NDAS／SANICAP.NDI／FID 17h.NODRM | 只有 NDI=1 且要求 NDAS=1 時，NODRM 才決定該衝突的回應。 | NODRM=0：Invalid Field in Command；NODRM=1：處理命令，成功時 SOS=100b，告知仍發生解除配置。NDI=0 時 NODRM 不影響行為。 |
| EMVS／GDE／後續狀態 | EMVS 要求在 sanitize processing 成功後進入 Media Verification；它是要求值，GDE 與狀態是結果資訊。 | EMVS=1 不能直接當成現在已進入驗證，仍需查詢 SANS。 |
| PMR enabled／pending firmware activation／controller suspended | 這些條件可能阻止開始 subsystem Sanitize，各自有命令專屬狀態。 | PMR 尚啟用與韌體待 reset 是不同原因；後者還需分辨所要求的 reset 類型。 |
來源：Base 2.4 §5.2.26 · Base 2.4 §5.2.30.1.16 · Base 2.4 §5.2.27
來源：NVME-BASE-2.4, Rev. 2.4, §5.2.26, Figure 451, 文件頁 450-451, PDF 頁 476-477
來源：NVME-BASE-2.4, Rev. 2.4, §5.2.26, Figure 452, 文件頁 451, PDF 頁 477
來源：NVME-BASE-2.4, Rev. 2.4, §5.2.26, Figure 453, 文件頁 451, PDF 頁 477
來源：NVME-BASE-2.4, Rev. 2.4, §5.2.30.1.16, Figure 492, 文件頁 477-478, PDF 頁 503-504
來源：NVME-BASE-2.4, Rev. 2.4, §5.2.27, Figure 454, 文件頁 453, PDF 頁 479
Base Figure 451 · Sanitize - Command Dword 10
一句話重點
Base451-1Sanitize 的 SANACT 決定方法，其他參數依方法才有意義。
來源：Base 2.4 §5.2.26
來源：NVME-BASE-2.4, Rev. 2.4, §5.2.26, Figure 451, 文件頁 450-451, PDF 頁 476-477
用例子讀懂
Base451-2選 Overwrite 後才解 OWPASS、OIPBP；OWPASS＝0 特別表示 16 輪，不是零輪。換成 Crypto Erase 時不能照搬 overwrite 參數。
Base Figure 452 · Sanitize - Command Dword 11
一句話重點
Base452-1OVRPAT 指定 Overwrite 使用的 32-bit pattern。
來源：Base 2.4 §5.2.26
來源：NVME-BASE-2.4, Rev. 2.4, §5.2.26, Figure 452, 文件頁 451, PDF 頁 477
用例子讀懂
Base452-2OVRPAT＝A5A5A5A5h 時，還要配合 OIPBP 與輪數判斷各輪是否反相；它不是進度或清除後資料量。
Base Figure 453 · Sanitize - Command Specific Status Values
一句話重點
Base453-1啟動 Sanitize 的命令失敗與背景清除失敗是不同階段。
來源：Base 2.4 §5.2.26
來源：NVME-BASE-2.4, Rev. 2.4, §5.2.26, Figure 453, 文件頁 451, PDF 頁 477
用例子讀懂
Base453-2命令因 PMR Enabled 被拒絕時，清除可能尚未開始；背景作業稍後失敗則要讀 Sanitize Status，不能只看啟動 CQE。
Base Figure 492 · Sanitize Config - Command Dword 11
一句話重點
Base492-1Sanitize Config 的 NODRM 控制相應的清除後配置行為。
來源：Base 2.4 §5.2.30.1.16
來源：NVME-BASE-2.4, Rev. 2.4, §5.2.30.1.16, Figure 492, 文件頁 477-478, PDF 頁 503-504
用例子讀懂
Base492-2需要判斷 NDAS 的效果時，連同 NODRM 與 SANICAP 閱讀；不能只看命令中的一個 bit 就推論所有資料是否重新配置。
方法支援、解除配置與清除保證分別檢查
05.11.SANICAP 的不同位元回答不同問題：能執行哪種方法、能否保留配置、以及是否支援更進一步的要求與回報。
| 一起判讀的欄位或標示 | 如何共同決定操作或結果 | 帶入情境後怎麼讀 |
|---|---|---|
| CES／BES／OWS | 分別回報 Crypto Erase、Block Erase 與 Overwrite 支援。 | 主機選 SANACT 前，先檢查對應方法位元；不能只看到 SANICAP 非零便使用任意方法。 |
| NDI／NODMMAS → NDAS／NODRM／估計時間 | NDI 表示 No-Deallocate 是否被禁止；NODMMAS 補充不解除配置時是否還要修改媒體。 | NDAS=1 且 NDI=1 時，NODRM 決定拒絕或以警告模式處理；若需要額外媒體修改，再使用對應時間欄位。 |
| SPRRS／PREQ | 支援 Purge Request and Reporting 時，PREQ 才按清除要求解讀。 | SPRRS=1、PREQ=1，而作業未達 Purge 要求時，應依規格回報作業失敗；命令被接受不保證已達此要求。 |
來源：Base 2.4 §5.2.14.2.1
來源：NVME-BASE-2.4, Rev. 2.4, §5.2.14.2.1, Figure 338, 文件頁 340-382, PDF 頁 366-408
Base Figure 338 · Identify - Identify Controller Data Structure, I/O Command Set Independent
一句話重點
Base338-1Identify Controller 先告知能力與限制，主機再決定可使用的操作。
來源：Base 2.4 §5.2.14.2.1
來源：NVME-BASE-2.4, Rev. 2.4, §5.2.14.2.1, Figure 338, 文件頁 340-382, PDF 頁 366-408
用例子讀懂
Base338-2規格列出某選用命令時，先查相應支援欄位再發出要求；「命令有定義」與「這台控制器支援」是不同證據。
Base Figure 454 · Sanitize Namespace - Command Dword 10
一句話重點
Base454-1Sanitize Namespace 的欄位與 subsystem Sanitize 不完全相同。
來源：Base 2.4 §5.2.27
來源：NVME-BASE-2.4, Rev. 2.4, §5.2.27, Figure 454, 文件頁 453, PDF 頁 479
用例子讀懂
Base454-2Namespace 命令的 PREQ 在 bit 4，且不含 subsystem 命令的 Overwrite 參數；不能把同一 CDW10 原值直接換操作碼重送。
圖表組 03 · 背景 Sanitize 的狀態與進度 · 12 張圖表
05.12.沿狀態圖辨認每個轉移所要求的動作，再將 SOS、SPROG 和失敗階段配對閱讀。Restricted 與 Unrestricted Failure 的可用出口不同；Media Verification 時的滿進度值也不能單獨證明整個 operation 已結束。
回到本節的解釋與範例把作業狀態、要求參數與時間估計接起來
05.13.同一份 log 同時保留狀態與補充資訊。讀取順序是目標、狀態、有效欄位、數值；不要從一個進度值直接跳到「資料已清除」的結論。
| 一起判讀的欄位或標示 | 如何共同決定操作或結果 | 帶入情境後怎麼讀 |
|---|---|---|
| SSTAT.SOS／SPROG | SOS 區分從未開始、完成、進行中、失敗及非預期解除配置。SPROG 依有效條件表示進度。 | SOS=010b 仍可能處於 Media Verification 或 Post-Verification Deallocation，不能說清除後的完整流程已結束。 |
| SSTAT.OPC／GDE／NDE／MVCNCLD／PRGD | OPC 是已完成覆寫次數；GDE 與 NDE 分別涉及 subsystem 與 namespace 資料狀態；MVCNCLD 記錄驗證是否取消；PRGD 在有效條件下回報 Purge 結果。 | 覆寫次數已達要求時，仍要讀 SOS 與後續狀態，不能只靠 OPC 宣告回到 Idle。 |
| SCDW10 | 保存啟動相關作業的命令 CDW10，讓狀態與 SANACT、NDAS、EMVS 等原始要求對得上。 | 先前選 Overwrite 時才把 OPC 當覆寫 pass 數；不要用 Crypto Erase 的紀錄解釋它。 |
| ETO／ETBE／ETCE／ETODMM／ETBENMM／ETCENMM／ETPVDS | 時間以秒表示；依方法、NDAS 與 NODMMAS 選欄位，驗證後解除配置另有估計。ETO 以 16 passes 為基礎。 | FFFFFFFFh 表示未回報時間，不能換算成數十年的剩餘等待；估計也不取代實際完成狀態。 |
| SSI.SANS／FAILS／VERS | 支援驗證狀態資訊時，SANS 回報目前狀態；FAILS 在 SOS 指出失敗時補充失敗發生的狀態。 | SANS 與 FAILS 的數字可能不同，因為前者是現在，後者是失敗發生時。 |
| MNSOIP／STNSID | MNSOIP 是允許同時執行的 namespace sanitize 作業數上限；STNSID 確認此次查詢目標。 | MNSOIP=4 不表示現在有 4 個作業。查 subsystem 時 STNSID=0；查 namespace 時 STNSID 回應要求的 NSID。 |
來源：Base 2.4 §5.2.13.1.38
來源：NVME-BASE-2.4, Rev. 2.4, §5.2.13.1.38, Figure 312, 文件頁 314-319, PDF 頁 340-345
Base Figure 312 · Sanitize Status Log Page
一句話重點
Base312-1Sanitize Status 將進度、狀態與啟動命令資訊放在同一份紀錄。
來源：Base 2.4 §5.2.13.1.38
來源：NVME-BASE-2.4, Rev. 2.4, §5.2.13.1.38, Figure 312, 文件頁 314-319, PDF 頁 340-345
用例子讀懂
Base312-2SPROG 看起來很接近完成時，仍須讀 SSTAT 判斷成功、失敗或其他狀態；不能只以百分比作完成證明。
先選處理模式，再理解失敗後可走的路
05.14.總狀態圖的箭頭代號要對回 transition 表。AUSE 決定 restricted 或 unrestricted 路徑；Idle 是狀態，不是每一種情況下都代表最近一次清除成功。
| 一起判讀的欄位或標示 | 如何共同決定操作或結果 | 帶入情境後怎麼讀 |
|---|---|---|
| A1／B1：Idle → Processing | AUSE=0 走 Restricted Processing，AUSE=1 走 Unrestricted Processing；開始時 SPROG 清為 0，MVCNCLD 清為 0。 | 同樣的方法可以走不同完成模式；先前進度 80% 不能延用到新作業。 |
| A2：Restricted Failure → Restricted Processing | 失敗後要以 AUSE=0 開始後續清除，不能用 Exit Failure Mode 直接回 Idle，也不能改成 AUSE=1 迴避限制。 | 受限失敗後送 Exit Failure Mode，依目標得到 Sanitize Failed 或 Sanitize Namespace Failed。 |
| A3／B2：Unrestricted Failure → Processing | 可用 AUSE=0 重新進入 Restricted Processing，或 AUSE=1 進入 Unrestricted Processing。 | 選 A3 是重新開始受限模式的清除，不表示上一次資料已被成功清除。 |
| E：Unrestricted Failure → Idle | Exit Failure Mode 可以讓狀態回 Idle，命令成功表示完成這項退出動作。 | 因此只讀 SANS=Idle 不足以證明 sanitize 成功；還要讀 SOS 的最近作業結果。 |
來源：Base 2.4 §8.1.27.4 · Base 2.4 §8.1.27.4.1 · Base 2.4 §8.1.27.4.3 · Base 2.4 §8.1.27.4.5
來源：NVME-BASE-2.4, Rev. 2.4, §8.1.27.4, Figure 772, 文件頁 720, PDF 頁 746
來源：NVME-BASE-2.4, Rev. 2.4, §8.1.27.4.1, Figure 773, 文件頁 721, PDF 頁 747
來源：NVME-BASE-2.4, Rev. 2.4, §8.1.27.4.3, Figure 775, 文件頁 724, PDF 頁 750
來源：NVME-BASE-2.4, Rev. 2.4, §8.1.27.4.5, Figure 777, 文件頁 727, PDF 頁 753
Base Figure 772 · Sanitize Operation State Machine
一句話重點
Base772-1Sanitize 狀態圖把處理、失敗、驗證及後續配置分開。
來源：Base 2.4 §8.1.27.4
來源：NVME-BASE-2.4, Rev. 2.4, §8.1.27.4, Figure 772, 文件頁 720, PDF 頁 746
用例子讀懂
Base772-2同樣回到可接受命令的情況，可能經成功完成或退出失敗模式；沿箭頭保留原因，不能只看終點名稱。
Base Figure 773 · Idle State Transition Conditions
一句話重點
Base773-1Idle 的離開條件依要求及 AUSE 選擇不同處理路徑。
來源：Base 2.4 §8.1.27.4.1
來源：NVME-BASE-2.4, Rev. 2.4, §8.1.27.4.1, Figure 773, 文件頁 721, PDF 頁 747
用例子讀懂
Base773-2同一清除方法分別設定 AUSE＝0、1，沿 A1、B1 看進入哪一個 processing state；方法與失敗限制選擇是不同參數。
處理結束後，成功、失敗與驗證分三條路
05.15.Restricted 與 Unrestricted Processing 的成功分支使用相同的 EMVS／MVCNCLD 條件；失敗時才分別進入不同的 Failure state。
| 一起判讀的欄位或標示 | 如何共同決定操作或結果 | 帶入情境後怎麼讀 |
|---|---|---|
| C1／C2 → Idle | 處理成功且 EMVS=0，或 EMVS=1 但 MVCNCLD=1 且要求的解除配置成功完成時，回到 Idle。 | 原本要求驗證但後來被取消，不能省略解除配置條件就直接宣告回 Idle。 |
| F1／F2 → Media Verification | 處理成功、EMVS=1 且 MVCNCLD=0，才進入驗證。 | 兩個條件要一起成立：只看命令 EMVS=1，仍不知道驗證是否被後續事件取消。 |
| D1／D2 → Failure；SSI.FAILS | 處理失敗時，依原模式進入 Restricted 或 Unrestricted Failure；FAILS 分別記 1h 或 3h，指出失敗發生在 processing。 | 目前 SANS 是 Failure，但 FAILS 是 Processing，這是目前狀態與失敗來源的差別。 |
| GDE／NDE／SANS／事件通知 | 成功轉移依 subsystem 或 namespace 目標更新相應 log 與資料狀態，並傳送相應完成或進入驗證事件。 | 清除單一 namespace 不能直接把其他 namespace 的 NDE 一起當成已更新。 |
來源：Base 2.4 §8.1.27.4.2 · Base 2.4 §8.1.27.4.4
來源：NVME-BASE-2.4, Rev. 2.4, §8.1.27.4.2, Figure 774, 文件頁 722, PDF 頁 748
來源：NVME-BASE-2.4, Rev. 2.4, §8.1.27.4.4, Figure 776, 文件頁 725, PDF 頁 751
Base Figure 774 · Restricted Processing State Transition Conditions
一句話重點
Base774-1Restricted Processing 的下一步由成功、失敗及驗證條件決定。
來源：Base 2.4 §8.1.27.4.2
來源：NVME-BASE-2.4, Rev. 2.4, §8.1.27.4.2, Figure 774, 文件頁 722, PDF 頁 748
用例子讀懂
Base774-2清除成功且需要媒體驗證時，沿驗證分支；發生失敗則沿另一條路徑，不把兩者都說成「處理結束」。
Base Figure 775 · Restricted Failure State Transition Conditions
一句話重點
Base775-1Restricted Failure 的恢復必須滿足該狀態允許的要求。
來源：Base 2.4 §8.1.27.4.3
來源：NVME-BASE-2.4, Rev. 2.4, §8.1.27.4.3, Figure 775, 文件頁 724, PDF 頁 750
用例子讀懂
Base775-2失敗後再次要求清除前，先看 A2 的條件；不能按 Idle 的可接受命令清單推論目前也相同。
Base Figure 776 · Unrestricted Processing State Transition Conditions
一句話重點
Base776-1Unrestricted Processing 有自己的成功、失敗與驗證轉移。
來源：Base 2.4 §8.1.27.4.4
來源：NVME-BASE-2.4, Rev. 2.4, §8.1.27.4.4, Figure 776, 文件頁 725, PDF 頁 751
用例子讀懂
Base776-2與 Figure 774 比較時，把相同清除結果放進兩種狀態，觀察後續限制如何不同，而不是重複背一樣的成功定義。
Base Figure 777 · Unrestricted Failure State Transition Conditions
一句話重點
Base777-1Unrestricted Failure 可以依允許的要求重試或退出失敗模式。
來源：Base 2.4 §8.1.27.4.5
來源：NVME-BASE-2.4, Rev. 2.4, §8.1.27.4.5, Figure 777, 文件頁 727, PDF 頁 753
用例子讀懂
Base777-2Exit Failure Mode 讓狀態改變，不等於先前失敗的清除突然成功；仍要保留失敗結果的含義。
驗證結束後，還有解除配置的完成點
05.16.Media Verification 允許依命令集規則讀取來驗證清除。離開此狀態後，必須追蹤 Post-Verification Deallocation，不能將退出驗證命令的成功回覆當成所有後續工作完成。
| 一起判讀的欄位或標示 | 如何共同決定操作或結果 | 帶入情境後怎麼讀 |
|---|---|---|
| G：Media Verification → Post-Verification Deallocation | 指定目標的 Exit Media Verification、適用的 NVM Subsystem Reset／transport reset，或使驗證無法繼續的組態變動都可能觸發此轉移。 | namespace 目標要檢查被 reset 的控制器與該 namespace 的附加關係，不能將任何控制器 reset 一概視為同一條件。 |
| SPROG／MVCNCLD | 轉入後續解除配置時 SPROG 清為 0；適用的 reset 或組態變動也會設 MVCNCLD。 | 進度從先前數值回到 0，可能是開始新階段；先讀 SANS，再判斷是不是同一階段倒退。 |
| H → Idle | 成功解除配置該目標中所有已配置的 user-data media 後才回 Idle。 | 只收到 Exit Media Verification 的成功 CQE，仍需等待這個背景階段的結果。 |
| I1／I2 → Failure | 解除配置失敗時，依啟動作業的 AUSE=0 或 1 分別回 Restricted 或 Unrestricted Failure。 | 同樣是後續解除配置失敗，允許的退出／重試路徑仍由原本模式決定；不能隨意選較寬鬆的 failure state。 |
來源：Base 2.4 §8.1.27.4.6 · Base 2.4 §8.1.27.4.7
來源：NVME-BASE-2.4, Rev. 2.4, §8.1.27.4.6, Figure 778, 文件頁 728, PDF 頁 754
來源：NVME-BASE-2.4, Rev. 2.4, §8.1.27.4.7, Figure 779, 文件頁 729, PDF 頁 755
Base Figure 778 · Media Verification State Transition Conditions
一句話重點
Base778-1Media Verification 的退出與 reset 有明確轉移條件。
來源：Base 2.4 §8.1.27.4.6
來源：NVME-BASE-2.4, Rev. 2.4, §8.1.27.4.6, Figure 778, 文件頁 728, PDF 頁 754
用例子讀懂
Base778-2驗證讀取完成後，依允許機制離開；若期間發生 reset，沿對應箭頭看下一狀態，不能假設永遠保留在驗證中。
Base Figure 779 · Post-Verification Deallocation state Transition Conditions
一句話重點
Base779-1Post-Verification Deallocation 的結果決定最終轉移。
來源：Base 2.4 §8.1.27.4.7
來源：NVME-BASE-2.4, Rev. 2.4, §8.1.27.4.7, Figure 779, 文件頁 729, PDF 頁 755
用例子讀懂
Base779-2已完成媒體驗證仍可能需要後續 deallocation；觀察 H、I1、I2 的條件，不能在進入此狀態時就宣布整個流程結束。
事件引導主機讀取作業的詳細狀態
05.17.Asynchronous Event 的完成資訊指出事件種類與相關 log；Sanitize Status 才提供目標、作業狀態與原始要求等內容。
| 一起判讀的欄位或標示 | 如何共同決定操作或結果 | 帶入情境後怎麼讀 |
|---|---|---|
| AET／AEI／LID／EVNTSP | 事件類別、事件資訊及 log identifier 一起指向相應結果；事件專屬資訊依該種類定義讀取。 | 收到清除相關事件後，先確認所指目標及 LID 81h 的狀態，不從 AER 的 Successful Completion 直接推論清除成功。 |
| Operation Completed／Unexpected Deallocation／Entered Media Verification | 這三種事件區分作業結束、非預期解除配置及進入驗證階段。 | Entered Media Verification 代表接下來可依規則驗證，與已回到 Idle 的完成通知不同。 |
來源：Base 2.4 §5.2.2.1
來源：NVME-BASE-2.4, Rev. 2.4, §5.2.2.1, Figure 151, 文件頁 184-185, PDF 頁 210-211
來源：NVME-BASE-2.4, Rev. 2.4, §5.2.2.1, Figure 152, 文件頁 185, PDF 頁 211
來源：NVME-BASE-2.4, Rev. 2.4, §5.2.2.1, Figure 156, 文件頁 189-190, PDF 頁 215-216
Base Figure 151 · Asynchronous Event Request - Completion Queue Entry Dword 0
一句話重點
Base151-1AER 完成的 DW0 指出事件類型、事件資訊與相關 log。
來源：Base 2.4 §5.2.2.1
來源：NVME-BASE-2.4, Rev. 2.4, §5.2.2.1, Figure 151, 文件頁 184-185, PDF 頁 210-211
用例子讀懂
Base151-2收到通知後，以 AET 分類、AEI 看具體事件，再用 LID 找後續資料；單看 LID 不足以知道發生什麼事。
Base Figure 152 · Asynchronous Event Request - Completion Queue Entry Dword 1
一句話重點
Base152-1AER 的 DW1 提供事件專用的補充資訊。
來源：Base 2.4 §5.2.2.1
來源：NVME-BASE-2.4, Rev. 2.4, §5.2.2.1, Figure 152, 文件頁 185, PDF 頁 211
用例子讀懂
Base152-2同一個 EVNTSP 數值在不同事件中不一定同義；先由 DW0 辨識事件，再按該事件解釋 DW1。
Base Figure 156 · Asynchronous Event Information - I/O Command Specific Status
一句話重點
Base156-1I/O Command Set 事件用不同通知區分清除完成與進入驗證。
來源：Base 2.4 §5.2.2.1
來源：NVME-BASE-2.4, Rev. 2.4, §5.2.2.1, Figure 156, 文件頁 189-190, PDF 頁 215-216
用例子讀懂
Base156-2Entered Media Verification State 與 Sanitize Operation Completed 不是同一事件；前者表示還有驗證階段的存取規則需要遵守。
圖表組 04 · 操作限制與驗證讀取 · 6 張圖表
05.18.先檢查是否處於 Media Verification，再依 PI 檢查要求及 allocated／deallocated 分支閱讀結果表。表中的特定成功狀態與一般 Successful Completion 要分辨，且不能用解除配置後的回傳值代替實體媒體觀察。
回到本節的解釋與範例先決定傳輸哪些資料，再決定檢查與產生哪些 PI
05.19.PRACT 選資料保護處理方式，PRCHK 的各 bit 選檢查項目；格式、metadata 大小與命令方向共同決定實際傳輸量。
| 一起判讀的欄位或標示 | 如何共同決定操作或結果 | 帶入情境後怎麼讀 |
|---|---|---|
| PRACT／MS／PI size | 結合所選格式判斷 PI 是隨資料傳輸，還是由控制器插入或移除。 | MS 大於 PI 大小時，移除 PI 不代表整份 metadata 都消失。 |
| GRDCHK／ATCHK／RTCHK／STC | Guard、Application Tag、Reference Tag 及 Storage Tag 的檢查分別選擇。 | 只選 Guard 檢查，不可宣稱同時驗證了所有 tag 的關聯。 |
| PRINFOR／PRINFOW；STCR／STCW | Copy 的來源讀取與目的寫入可有不同處理；兩端的選擇需要成對閱讀。 | 來源有 PI、目的沒有 PI 的 Strip，與來源沒有 PI、目的需要 PI 的 Insert，資料流方向相反。 |
| 來源資料／主機資料／比較結果 | Compare 先依設定處理與檢查，再比較指定資料；錯誤可來自不同階段。 | PI 檢查失敗與資料比較不相等，不能合成同一種 Compare Failure。 |
- Guard
- PI 的檢查值欄位；所選格式決定檢查值的寬度與計算方法。
來源：NVM Command Set 1.3 §2.1.5
來源：NVME-NVM-CS-1.3, Rev. 1.3, §2.1.5, Figure 11, 文件頁 21-22, PDF 頁 21-22
來源：NVME-NVM-CS-1.3, Rev. 1.3, §2.1.5, Figure 12, 文件頁 22, PDF 頁 22
NVM Figure 11 · Protection Information Field Definition
一句話重點
NVM11-1PRACT 決定 PI 的處理方式，PRCHK 決定要進行哪些檢查。
來源：NVM Command Set 1.3 §2.1.5
來源：NVME-NVM-CS-1.3, Rev. 1.3, §2.1.5, Figure 11, 文件頁 21-22, PDF 頁 21-22
用例子讀懂
NVM11-2同樣 PRACT＝1，metadata 大小等於 PI 大小或大於 PI 大小時，傳輸的內容可能不同；要沿表中相應列追資料，而非只看 PRACT。
NVM Figure 12 · Storage Tag Check Definition
一句話重點
NVM12-1Storage Tag 是否存在，決定 STC 檢查要求是否有對象。
來源：NVM Command Set 1.3 §2.1.5
來源：NVME-NVM-CS-1.3, Rev. 1.3, §2.1.5, Figure 12, 文件頁 22, PDF 頁 22
用例子讀懂
NVM12-2STS＝0 表示沒有 Storage Tag，因此設定 STC 也不會憑空產生一個要比對的 tag；改成非零 STS 後才有對應位元。
支援表的列、欄與註腳必須一起讀
05.20.表格先以命令、log 或 Feature 選一列，再以控制器類型或目前狀態選一欄。M／O 等標記及數字註腳說明支援要求與條件，不能將抽出的 O8、M3 當成另一個 NVMe 欄位。
| 一起判讀的欄位或標示 | 如何共同決定操作或結果 | 帶入情境後怎麼讀 |
|---|---|---|
| 命令／LID／FID 的列 | 三者是不同識別空間；選列前先確認目前使用哪一類操作。 | Get Log Page 的 LID 與 Set Features 的 FID 即使同為 0Bh，也要查各自的表。 |
| 控制器類型／處理狀態的欄 | 控制器類型決定支援要求；清除期間的狀態欄則限制當時接受的操作。 | 裝置平常支援某命令，並不表示 Restricted Processing 中仍允許執行。 |
| 條件註腳 | 說明支援位元、所需能力或例外，需與對應儲存格合讀。 | 一列標示 optional 時，先查控制器宣告的能力，再決定能否使用。 |
來源：Base 2.4 §5.1.1 · Base 2.4 §5.1.2
來源：NVME-BASE-2.4, Rev. 2.4, §5.1.1, Figure 144, 文件頁 178-179, PDF 頁 204-205
來源：NVME-BASE-2.4, Rev. 2.4, §5.1.2, Figure 145, 文件頁 179-180, PDF 頁 205-206
來源：NVME-BASE-2.4, Rev. 2.4, §5.1.2, Figure 146, 文件頁 180-181, PDF 頁 206-207
Base Figure 144 · NVM Subsystem Sanitize Operations and Format NVM Command - Admin
一句話重點
Base144-1Subsystem Sanitize 期間的 Admin 命令限制依命令與清除狀態而定。
來源：Base 2.4 §5.1.1
來源：NVME-BASE-2.4, Rev. 2.4, §5.1.1, Figure 144, 文件頁 178-179, PDF 頁 204-205
用例子讀懂
Base144-2想讀 Boot Partition log 時，先查這一列在目前清除情境是否允許，不把其他 log 的許可套用過來。
Base Figure 145 · Namespace Sanitize Operations - Admin Command Restrictions, All Controllers
一句話重點
Base145-1Namespace Sanitize 對所有控制器的管理操作有共同限制。
來源：Base 2.4 §5.1.2
來源：NVME-BASE-2.4, Rev. 2.4, §5.1.2, Figure 145, 文件頁 179-180, PDF 頁 205-206
用例子讀懂
Base145-2清除某個 namespace 時，另一控制器送出的管理操作也可能受影響；限制範圍不只送出清除命令的控制器。
Base Figure 146 · Namespace Sanitize Operations - Admin Command Restrictions if Sanitizing
一句話重點
Base146-1與正在清除的 namespace 有關的控制器還有額外限制。
來源：Base 2.4 §5.1.2
來源：NVME-BASE-2.4, Rev. 2.4, §5.1.2, Figure 146, 文件頁 180-181, PDF 頁 206-207
用例子讀懂
Base146-2比較附加該 namespace 與未附加它的控制器時，先套用共同限制，再看這張表的條件是否成立。
清除造成的存取狀態變動使用另一份 log
05.21.Reservation Notification 回報 reservation 相關事件。本篇引用它是為了解釋清除流程中的存取狀態變動；清除進度仍由 LID 81h 取得。
| 一起判讀的欄位或標示 | 如何共同決定操作或結果 | 帶入情境後怎麼讀 |
|---|---|---|
| Log Page Count／Notification Type／NSID | 計數辨認通知紀錄，類型說明 reservation 變動，NSID 指向受影響對象。 | 通知中的 NSID=7 是要刷新存取狀態的 namespace，不表示 namespace 7 的 Sanitize 已完成 7%。 |
來源：Base 2.4 §5.2.13.1.37
來源：NVME-BASE-2.4, Rev. 2.4, §5.2.13.1.37, Figure 311, 文件頁 313, PDF 頁 339
Base Figure 311 · Reservation Notification Log Page
一句話重點
Base311-1Reservation Notification log 描述保留狀態相關通知。
來源：Base 2.4 §5.2.13.1.37
來源：NVME-BASE-2.4, Rev. 2.4, §5.2.13.1.37, Figure 311, 文件頁 313, PDF 頁 339
用例子讀懂
Base311-2收到通知後先看通知種類與計數，確認是否需要重新讀取保留狀態；通知紀錄本身不是完整使用者資料。
學完後想一想
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