Format 與 Sanitize

1. 要查哪個對象、哪份資料

Format 的範圍由 FNA、SES 與 NSID 決定；Sanitize 和 Sanitize Namespace 則是不同命令、不同清除目標。

NSID

Namespace Identifier，邏輯儲存空間識別碼

Format 查 OACS 與 FNA；Sanitize 查 SANICAP 的 CES、BES、OWS。要確認 Sanitize Namespace 命令本身，先由 Figure 28 找到 Admin Opcode 8Ch，再讀 LID05h 的對應 Admin entry，以 Figure 217 的 bit0（CSUPP）判讀。CSUPP 是命令支援宣告；SANICAP.CES、NVERS 則分別補充清除方法與 namespace 媒體驗證能力。

Format NVM、Sanitize、Sanitize Namespace 的 Admin Opcode 分別是 80h、84h、8Ch。這裡要送出的查詢命令是 Identify（06h）與 Get Log Page（02h）；Get Log Page 的 LID=05h 才選到命令支援表。不能把 8Ch 填進 LID，也不能只查 Get Log Page 本身的 CSUPP，就當成所有 Log 或所有管理命令都受支援。

2. 查詢順序與回覆判讀

先確認查詢通道與 Log 支援，再讀正確 entry；若 CSUPP=1，才繼續查方法、參數與目標狀態。查詢過程只讀取資訊，不需要啟動清除。準備真的執行時，才進一步確認 Active NSID、寫入保護、Sanitize 狀態、並行上限與待啟用韌體限制。

Identify 與 Get Log Page 成功，表示已取得可判讀的能力資料。若 8Ch 的 CSUPP=1，可以回答「controller 宣告支援 Sanitize Namespace」；這不表示 NSID=7 現在一定能接受命令，更不表示資料已經清除。

3. 證據不足或不一致時怎麼判斷

查詢 LID05h 不受支援時，Get Log Page 一般以 Invalid Log Page（1/09h）失敗；這時沒有有效的 CSUPP 可讀，不能當成 CSUPP=0。真正提交不支援的 Opcode，與受支援命令使用非法 SANACT，是另外兩種條件，分別按 Invalid Command Opcode（0/01h）與 Invalid Field in Command（0/02h）判斷。

交叉比對時，要保持 controller、命令集與查詢時點一致。CSUPP=1 但操作失敗時，先排除非法參數及目前狀態；CSUPP=0 卻有同一命令的合法成功行為，才構成需要追查的支援宣告矛盾。SANICAP.OWS=1 也不會把 namespace Overwrite 變成合法操作。

先確認讀的是 LID05h 的 Admin 區、Opcode8Ch 那一筆，並且 Get Log Page 已成功。讀錯 84h、漏掉位移單位，或把失敗查詢留下的 buffer 當成有效資料，都會讓支援結論出錯。

1. 差別在哪裡

Format 依 FNA／SES／NSID 選範圍；Subsystem Sanitize 包含其規定的全部使用者資料位置；Namespace Sanitize 只清除指定 namespace 的資料範圍。

Format 的 SES=0 不要求 Secure Erase，1 為 User Data Erase，2 為 Cryptographic Erase。Sanitize 的 SANACT 另行選擇方法；Namespace Sanitize 只支援 Crypto Erase。

2. 如何選擇與確認

檢查 OACS、FNA、SANICAP、namespace 狀態及支援的格式。不能只看到「Crypto Erase」同名，就省略命令範圍差異。

先回答要改格式、清除哪個範圍、是否需要指定清除方法，再選命令。所有 namespace 各做一次 Sanitize，也不等於 subsystem 的全部使用者資料位置都已處理。

Format CQE 在格式化完成後回傳；Sanitize 啟動成功後仍以背景方式進行，要另查 LID81h。

3. 比較時要保留的條件

不合法格式使用 Invalid Format；不支援 SANACT 使用 Invalid Field。各命令的拒絕條件不能互相套用。

例如需要改成 4 KiB LBA，應選 Format；需要清除整個 subsystem，不能只指定一個 namespace 然後把 NDE 當 GDE。

LBA

Logical Block Address，邏輯區塊位址

1. 操作前先準備什麼

設定適用於 Format 所涵蓋的 namespaces，不是只在這一筆命令中暫時使用。

讀 Identify Namespace 的 LBAF／FLBAS、MC、DPC、DPS，以及需要時的 NVM 特定格式擴充；確認 Host Behavior Support.LBAFEE。

CDW10 的 LBAFL 與有效時的 LBAFU 組成格式索引；MSET 選 extended LBA 或獨立 metadata buffer；PI 選 0～3；本版 NVM PIL 必須為 0。SES 另決定是否 Secure Erase。

2. 先後順序與完成條件

選定一個已宣告的格式，確認 metadata 與 PI 能力，再組合欄位。假設 LBAF2 是 4096-byte data＋16-byte metadata，MSET=1 時每個 extended LBA 傳輸長度是 4112 bytes。

成功後 FLBAS／DPS 應反映設定；logical block 大小改變時，NSZE／NCAP 可能改變，應重新讀取。

3. 未符合條件時如何處理

未支援格式回 Invalid Format；未啟用必要 LBAFEE 的格式回 Invalid Namespace or Format。共享 FDP RUH 還須符合共同格式限制。

FDP

Flexible Data Placement，彈性資料放置

用新格式重算 I/O data／metadata 長度，不要沿用 Format 前的 buffer 設定。

1. 先區分是哪一種失敗

先計算 Format 的完整範圍，再查其中每個 namespace；只要範圍內有寫入保護，就不能只看提交時指定的 namespace 是否可寫。

Invalid Format=1/0Ah；Invalid Namespace or Format=0/0Bh；Namespace is Write Protected=0/20h；Command Sequence Error=0/0Ch；Format In Progress=0/84h。

Format 影響的 namespace 尚有 I/O 時，controller 可中止 Format；若因此中止，應回 Command Sequence Error。這裡的「可」不能改寫成每次都必須拒絕。

2. 用哪些資料確認原因

用 LBAF、LBAFEE、FNA、Write Protection 狀態，以及現有 I/O／Admin 操作確認前提。

負向測試一次製造一項問題。例如測不支援 LBAF，先確保 NSID 合法、未受保護、沒有其他操作衝突。

3. 結果與後續驗證

正確拒絕不等於格式已改變；讀回設定以確認未將失敗命令錯當成成功操作。

測試需分清 shall、should、may，以及同時多錯誤時的 Status 選擇自由。

先看是否同時觸發保護與非法格式，導致精確 Status 斷言沒有唯一答案。

1. 機制與適用範圍

限制取決於操作是否影響正在 Format 的 namespace，以及 Figure144 對命令或 Log 的附加條件。

常見允許項包含 Abort、AER、queue 建立／刪除、Identify、Get Features、Get Log Page 的指定 LID 及 Keep Alive。Set Features 中的 Namespace Write Protection Config 不允許。

2. 用操作與結果理解

先確認命令本身受支援，再查 Format 期間的允許清單；列在允許清單不會讓選配功能自動變成支援。

以 Figure144 逐項檢查。Error Information 的 LBA 回 0；Self-test 僅 Controller DST 建議允許；不能由「Get Log Page 允許」推論所有 LID 都允許。

允許的查詢回目前狀態，不表示 Format 已完成。Format 的 CQE 或完整結果證據仍要另外確認。

3. 容易誤判的地方

未列出的 Admin 若影響被 Format 的 namespace，可中止；因這項理由中止時，建議回 Format In Progress。反向的操作衝突則可能使 Format 回 Command Sequence Error。

分別驗證命令允許性、LID 限制與回傳欄位，不用一筆 Get Log 成功概括全部管理操作。

1. 先界定觸發方式與影響對象

檢查原 Format 範圍內所有 namespaces，以及其他 controller 對共享 namespace 的存取狀態。

讀 Identify Namespace 的 FLBAS、DPS、NSZE／NCAP、支援時的 FPI，及 PEL Format Completion。

2. 哪些狀態改變，恢復後怎麼處理

Format Completion Event 的 FNVMS 說明格式化結果，INFO 保存曾回報的 Status；沒有 CQE 時 INFO=0 不能當成功。

先恢復 controller 與 Admin Queue，再保存事件、讀回新格式、確認可用性；若仍無法確定操作完成，就不要直接以舊格式恢復 I/O。

可以確認目前格式與完成狀態後，Host 才配置對應 buffer 與 PI。若需重新 Format，先依目前能力與範圍建立新命令。

3. 重設或斷電時，要確認什麼

4. 如何驗證保留或恢復結果

Reset 不保證原資料可復原，Power Cycle 也不是撤銷 Format 的方法；未收到成功不代表舊資料安全。

把 Reset 之前最後可信的事件與恢復後第一份快照連起來，標示中間不可觀察的期間。

先查是否有可信的 Format 成功 CQE；若沒有，避免直接用 INFO=0 補出成功結論。

1. 操作前先準備什麼

更新的是受影響 namespace 的格式及相關容量；Format 不等同 Create／Delete，不能預設一定產生新 NSID。

查 Identify Namespace 與必要的 NVM 特定結構，確認 FLBAS、DPS、LBAF、NSZE、NCAP 與 FPI。

FLBAS 表示使用中的格式及 metadata 傳輸方式；DPS 表示 PI 設定；NSZE／NCAP 以新的 logical block 為單位。

2. 先後順序與完成條件

等待 Format 成功 CQE，重新 Identify，再依新格式重算 LBA 範圍與 buffer 大小；有共享存取者時同步更新它們的配置。

設定讀回應與命令要求一致；若 block 大小改變，NSZE／NCAP 可能不同，不能用「數字必須完全不變」驗證容量。

3. 未符合條件時如何處理

若成功 CQE 後仍回舊格式，先排除讀錯 NSID、讀到快取或命令範圍誤判，再確認不一致。

例如同一容量從 512-byte 改為 4096-byte LBA，應比較以 bytes 表示的容量及允許變化，而不是只比較 block 數。

1. 先保留哪些證據

證據需對應同一筆 Format 及同一範圍；其他 namespace 的事件不能當成這筆命令的結果。

保存 CQE 的 SCT／SC／M／DNR，及 PEL 支援與事件有效性。

SCT

Status Code Type，完成狀態代碼類型

DNR

Do Not Retry，命令重試的狀態提示

Error Log 用 SQID／CID／ECNT 關聯；Format Start 保存參數，Completion 的 FNVMS／INFO 記錄結果與曾回報狀態。

SQID

Submission Queue Identifier，提交佇列識別碼

CID

Command Identifier，同一提交佇列內的命令識別碼

2. 依什麼順序排除原因

先看 Format 是否已進入執行階段，以及 PEL 是否存在相符的 Start／Completion。

先讀原 CQE，再依 M 取得補充資訊，最後以 PEL 與 Identify 現況補足過程。缺少某種記錄時先確認其要求，不硬湊三份一對一證據。

3. 把觀察結果接回規格條件

能說明失敗原因及目前是否可用，就是有效診斷。若結果仍不確定，保留不確定性而不是假設格式化回復。

Multiple errors 可能有不同合法 Status；INFO=0 也可能只是沒有 CQE，不可以忽略 FNVMS。

把命令參數、結果與目前格式比對，檢查是否有「回報成功但格式不符」或「失敗卻被 Host 視為成功」的矛盾。

4. 分開核對事件通知與 Log 紀錄

成功後重新讀 Identify Namespace 的格式與容量，並查看 Changed Namespace 清單。 完整條件見本冊說明

支援 PEL 與對應事件時，Format Start（07h）保存要求，Format Completion（08h）保存操作結果。 完整條件見本冊說明

1. 先確認資料的來源與範圍

CES、BES、OWS 對應 subsystem 清除方法；namespace 清除另有能力宣告，且本版只定義 Crypto Erase。

讀 Identify Controller.SANICAP，並交叉查 Command Effects 中的 84h／8Ch 與 LID81h 支援。

2. 欄位、單位與判讀例子

CES、BES、OWS 分別為 Crypto Erase、Block Erase、Overwrite 支援位元；NODAS／NDI 相關能力決定 NDAS 的意義，VERS／NVERS 則分別控制兩種目標的 Media Verification。

把需求的方法對到它的能力位元，再選對 SANACT。假設只有 BES=1，就選 subsystem Block Erase，不能改用 Overwrite。

合法啟動回 Success，且對應 Sanitize Status 已更新；能力支援不保證每次背景清除都能成功。

3. 判讀時要保留的條件

支援命令但 SANACT 不受支援時，必須回 Invalid Field in Command。

若不同 controller 屬於同一 subsystem，支援的相同 Sanitize 命令類型應一致；再另外驗證各命令的目標能力。

1. 先確認資料的來源與範圍

這些 Overwrite 與 NDAS 欄位屬 subsystem Sanitize，不能照搬到 Sanitize Namespace 的 CDW10。

確認 OWS、No-Deallocate Inhibited 與 No-Deallocate Modifies Media After Sanitize，必要時讀 FID17h.NODRM。

2. 欄位、單位與判讀例子

SANACT=3 選 Overwrite；OVRPAT 為 32-bit pattern；OWPASS=0 表示 16 次，1～15 表示該次數；OIPBP=1 在各次之間反轉 pattern。

假設 OVRPAT=AAAAAAAAh、OWPASS=2、OIPBP=1，兩次分別使用 AAAAAAAAh 與 55555555h。再獨立決定是否請求 NDAS。

成功後讀 SOS、完成 passes 與 GDE；若資料被 deallocate，Read 結果應依 deallocated LBA 規則，不保證仍讀出最後 pattern。

3. 判讀時要保留的條件

NDAS=1 但被 NDI 禁止時，NODRM=0 拒絕為 Invalid Field；警告模式可執行並回報 Unexpected Deallocate。非 Overwrite 時覆寫欄位按規定忽略。

比較要求的 pattern／passes、Log 保存的 SCDW10 與實際完成狀態；不要把 OWPASS=0 解成沒有做任何覆寫。

1. 先確認資料的來源與範圍

LID81h 依 NSID 選 subsystem 或指定 namespace；namespace 回覆中的 NDE 不能當成整個 subsystem 的 GDE。

確認 SANICAP 與 verification 能力，再讀同一目標的整份一致狀態快照。

2. 欄位、單位與判讀例子

SPROG／65536 是適用處理階段的完成比例；SOS 表示未開始、成功、進行中、失敗等；SANS 指狀態機位置；GDE／NDE 還會受後續使用者寫入影響。

先看 SOS 是否仍 Sanitizing，再看 SANS 在 Processing、Media Verification 或 Post-Verification Deallocation，最後才解讀 SPROG。

SPROG=8000h 在適用處理階段代表約 50%；FFFFh 在未處理或 Media Verification 時也可出現，不是獨立成功證據。

3. 判讀時要保留的條件

Get Log 查錯目標可有 Invalid Namespace or Format；subsystem 正在清除時讀 namespace 狀態另有 Sanitize In Progress 限制。

比較 SCDW10 與原要求，避免把先前一次清除的結果當成這次結果；再查看後續是否已有寫入清除 GDE／NDE。

1. 機制與適用範圍

限制適用於 subsystem 的全部 controller；換另一個 controller 不能繞過同一清除狀態。

Identify、AER、Get Features、queue 管理及指定 Log 可用；Sanitize Status 可查。PEL 與 vendor-specific Log 在此清除期間禁止，Self-test 也禁止；Error Log 的 LBA 必須回 0。

2. 用操作與結果理解

查 Figure144、Sanitize 狀態機，以及 NVM Figure200／201 的命令集補充。

先判斷狀態，再按命令及 LID 套限制。一般 I/O 受阻；Flush 與 Media Verification Read 有特別規則，不能用「全部 I/O 一律禁止」蓋過例外。

允許的命令正常完成；不允許的命令被拒絕，而背景 Sanitize 繼續。清除進度查詢建議不要過度頻繁，以免干擾進度。

3. 容易誤判的地方

進行中通常回 Sanitize In Progress；進入 failure state 後須依命令類型與失敗規則處理，不能把進行中與失敗混為一個狀態。

驗證同一限制是否在所有相關 controller 生效，也檢查允許的 Get Log 沒有洩漏應清除的使用者資料欄位。

1. 先界定觸發方式與影響對象

持續的是所選清除目標的狀態機與操作，不是原本已消失的 Admin Queue 或 AER Request。

重新讀 LID81h，確認 SOS、SANS、SCDW10、MVCNCLD 與目標 NSID；先恢復管理通道才能查詢。

2. 哪些狀態改變，恢復後怎麼處理

MVCNCLD 表示 Media Verification 被取消。傳輸層或 Subsystem Reset 的特定條件會設定它，不能把它解讀成 Sanitize 取消。

重設前保存狀態；恢復後先讀同一目標的 Log，再判斷是否繼續處理、轉入 deallocation 或已完成，不直接重新開始另一筆操作。

合理結果是背景操作持續或已依狀態機完成；斷電期間沒有處理進度並不違規，但恢復後不能忘記操作。

3. 重設或斷電時，要確認什麼

4. 如何驗證保留或恢復結果

仍在處理時重送啟動要求可能被 Sanitize In Progress 拒絕。不要將這個拒絕誤判成 Reset 後功能損壞。

檢查原參數、目標及狀態延續，再與重新建立的 AER／Log 查詢區分。

先確認查的是原目標，而不是在 namespace 清除後改查 subsystem Log。

1. 先保留哪些證據

以同一 target 的 SOS 與 SANS 判斷；namespace 失敗不能直接當成整個 subsystem 的最後清除結果。

讀 LID81h；支援相關 verification 資訊時另讀 FAILS 與 MVCNCLD，補足在哪一階段失敗。

SOS=001b 為 Sanitized，010b 為 Sanitizing，011b 為 Sanitize Failed，100b 為 Sanitized Unexpected Deallocate；SANS 再指出 Idle、Processing 或 Failure 等實際狀態。

2. 依什麼順序排除原因

先看 SANS，確認讀者所說的「失敗模式」真的是目前狀態，而不是歷史結果。

先查看結果，再判斷當前是否仍被失敗限制阻擋。若 SANS=Idle 但 SOS=Failed，確認是否曾執行合法 Exit Failure Mode。

3. 把觀察結果接回規格條件

成功不只看 SPROG；失敗也不是只看命令 CQE。背景失敗應由狀態與事件反映。

Restricted Failure 與 Unrestricted Failure 的允許復原動作不同。不能從兩者相同的 Failed 結果推論可使用相同恢復操作。

將 SOS、SANS、原 AUSE 及後續復原要求放在一起，檢查是否存在不合法的狀態轉移。

1. 機制與適用範圍

動作針對指定清除目標；subsystem 與 namespace 各有狀態機。

SANACT=001b 表示 Exit Failure Mode。它不是新一次 Block／Crypto／Overwrite 清除。

2. 用操作與結果理解

先讀 SANS 與原 SCDW10.AUSE。AUSE 決定操作進入 restricted 或 unrestricted 路徑。

Unrestricted Failure 可藉此回 Idle；Restricted Failure 必須以符合限制的新清除操作復原。Idle 收到此動作不視為錯誤。

合法退出後可回到允許正常存取的狀態，但 SOS 仍可報告最近操作失敗，GDE／NDE 也不能憑退出動作設成成功清除。

3. 容易誤判的地方

Restricted Failure 的 Exit Failure Mode 會依目標回相應 Sanitize Failed 類型；不能用反覆重送或 Reset 繞過限制。

驗證成功退出後的 SANS 與失敗歷史同時合理，而不是要求 Log 全部清零。

1. 事件何時成立、由誰觀察

AER 由啟動操作的 controller 回報；事件參數與 PEL.NSID 協助辨別 subsystem 或 namespace 目標。

確認通知支援、相關 AEC 設定、outstanding AER 與 PEL 支援。

AER 的 AET=6、LID=81h；AEI=01h 是 Completed，02h 是 Unexpected Deallocation，03h 是 Entered Media Verification。DW1 依定義標示目標。

2. 通知、讀取與確認的關係

啟動後記 Start；進入驗證先通知驗證階段；操作進入 Idle 或 Failure 才形成相應完成事件。收到通知後讀同一目標的 Log。

Completed 通知可以對應失敗完成，因此仍需讀 SOS／SANS。PEL Completion 同樣要看 SSTAT，不能只看事件名稱。

3. 沒有通知或紀錄時怎麼判斷

沒有 AER Request 時不能期待立刻收到 CQE；事件是否保留與遮蔽仍遵循 AER 規則。也不要在 Sanitize 期間強迫讀取當時不允許的 PEL。

對照事件的目標、原命令與 Log 狀態，區分「通知未送達」與「背景操作沒有完成」。

先查 AEC、AER Request 及回報 controller，再判斷通知是否真的缺失。

4. 分開核對事件通知與 Log 紀錄

依狀態轉移回報 Sanitize Operation Completed、Completed With Unexpected Deallocation 或 Entered Media Verification State，AER 的 LID=81h。 完整條件見本冊說明

支援對應 PEL 事件時，進入 Processing 記錄 Sanitize Start（09h）；進入 Idle、Restricted Failure 或 Unrestricted Failure 記錄 Completion（0Ah）。 完整條件見本冊說明

1. 操作前先準備什麼

NSID 指定一個 active namespace；其他 controller 若能存取同一 namespace，也必須遵守該目標的清除限制。

先查 LID05h 中 Admin Opcode8Ch 的 CSUPP，再查 SANICAP.CES 及所需的 NVERS／SPRRS 能力；查詢路徑見 Q118。接著確認 Active List、Write Protection 與 MNSOIP 並行上限，不能把命令受支援直接當成目標目前可執行。

Opcode8Ch、SANACT=100b；PREQ 在 CDW10 bit4，不是 subsystem Sanitize 的 bit11。用該 NSID 讀 LID81h 與 NDE。

2. 先後順序與完成條件

先保存目標與非目標 namespace 的資料／狀態基準，再啟動並追蹤目標。完成後驗證目標清除結果，並確認非目標資料未因這次操作被清除。

目標 NDE 可設為 1；其他 namespace 逐一清除也不能自行推成 GDE=1，因 subsystem 清除範圍還包含其他位置。

3. 未符合條件時如何處理

NSID=0、FFFFFFFFh、inactive 或正在刪除會被 Invalid Namespace or Format 拒絕；寫入保護另回 Namespace is Write Protected。

將資料內容隔離、目標 I/O 限制與全域韌體更新限制分別記錄；非目標資料不被清除，不代表所有管理命令都不受影響。

1. 先區分是哪一種失敗

檢查指定 namespace 與 subsystem 目前的清除狀態；subsystem failure 也可能阻止新 namespace 操作。

SANACT 只有 Crypto Erase 與狀態管理動作，010b／011b 在 Namespace 命令是保留值。

非法目標用 Invalid Namespace or Format；非法 SANACT 用 Invalid Field；超限用 Request Exceeds Maximum Namespace Sanitize Operations In Progress。原文 Figure104 列 3Ch，Figure455 列 12h，兩表有差異，不能擅自把其中一值當唯一驗收依據。

2. 用哪些資料確認原因

先讀 LID05h 中 Admin Opcode 8Ch 的 CSUPP，確認命令受支援。接著以 SANICAP 確認清除方法，從 Active／Allocated Lists 與 Write Protection 核對目標狀態，最後用 LID81h.MNSOIP 檢查並行限制。依這個順序，才能把支援能力接到目前目標的執行條件；完整查詢路徑見 Q118。

先用合法基準驗證支援，再分別測非法 NSID、寫入保護、非法 SANACT 與並行超量；保留每次測試前的狀態。

3. 結果與後續驗證

若啟動命令以非 Success 完成，不得為該命令開始清除、改寫該目標 Sanitize Status 或改變使用者資料。

除核對 Status，也驗證被拒絕的要求沒有啟動背景操作或改寫目標資料。

先確認是在驗證哪一個單獨失敗條件；並行數值爭議則保留原文兩處定位供查證。