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

回覆屬於收到命令的介面與 controller。不同介面可能支援不同 Log；CC.CSS=110b 時，CSI 與已啟用的 Command Set Profile 也會影響結果，不能把另一個介面的清單直接當成本介面的能力。

CSI

Command Set Identifier，命令集識別碼

Get Log Page 使用 LID=00h。Identify.LPA.MLPS=1 保證提供 Supported Log Pages；MLPS=0 仍可能提供，不能直接判成所有 Log 都不支援。LPA.LPEDS（Figure338 bit2）說明延伸 offset 與長度能力；目標 entry 的 LSUPP、IOS 則分別表示該 LID 是否支援及是否接受 index offset。

整張表有 256 個 4-byte entries。LID=n 的 entry 位於 4×n；bit0 是 LSUPP，bit1 是 IOS，高位 LIDSP 另依該 Log 定義。LSUPP=0 時，Host 應忽略其餘欄位。

2. 查詢順序與回覆判讀

先選對 controller 與命令集，讀取 00h，再找到目標 LID 的 entry。確認支援後，才依該 Log 的 scope、長度及參數讀取內容；能力在韌體或配置變更後需要重新確認。

成功取得的是能力表，不是各 Log 的內容。例如 LID=81h 的 LSUPP=1，只能證明可以查 Sanitize Status，不能據此宣稱已執行或完成 Sanitize。

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

不支援的 LID 一般回 Invalid Log Page（1/09h）；若 LSUPP=1，卻使用不支援的 OT=1，回 Invalid Field（0/02h）。兩者分別是 Log 不支援與讀取方式非法。

將 LSUPP、IOS、LPA 與實際合法查詢一起比較。不能要求所有支援的 Log 都支援 index offset，也不能用一次非法參數失敗推翻 LSUPP。

先確認清單與後續命令來自同一介面、相同 CSI 及設定期間，再檢查目標 entry 是否按 4 bytes 定位。

CSI

Command Set Identifier，命令集識別碼

1. 差別在哪裡

LID01h 是 controller 的錯誤紀錄。LID02h 可依支援情況接受 namespace 查詢，但 Base 2.4 明確指出本版沒有 namespace-specific SMART 欄位，因此兩種回覆包含相同資訊，不能自行標成各 namespace 的獨立使用量。

01h 每筆 64 bytes，重點是 ECNT、SQID、CID、Status、參數錯誤位置與 NSID。02h 為 512 bytes，重點是 Critical Warning、溫度、spare、Percentage Used，以及資料量、命令、時間和錯誤累計。

SQID

Submission Queue Identifier，提交佇列識別碼

CID

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

2. 如何選擇與確認

ELPE+1 表示最多可讀多少個 Error Information entries；LPA 的 SMART 支援位決定是否接受 per-namespace 請求。先確認支援，再解讀 Log 內容。

遇到錯誤時先保存 CQE，接著讀 01h 對回命令，再以同時段 02h 觀察健康狀態。先記錄取樣時間，避免將很久以前的錯誤與目前警告錯配。

CQE

Completion Queue Entry，佇列中的完成項目

成功讀取不代表裝置沒有錯誤。ECNT=0 表示該 entry 無效；Percentage Used=100 表示估計耐久度已耗用，並不直接表示裝置已失效。

3. 比較時要保留的條件

不支援 per-namespace SMART 卻指定一般 NSID，須回 Invalid Field（0/02h）。Log 中的舊錯誤 Status 是紀錄內容，與本次 Get Log Page 的完成 Status 不同。

SMART 的 Error Log Entries 累計不等於目前 01h buffer 裡的有效筆數；有限容量與重設清除可能讓歷史總量大於現存 entries。

1. 差別在哪裡

03h 的資料依 multi-domain 能力屬於 domain 或 subsystem；04h 描述此 controller 的 attached namespace 變更；05h 的命令支援則以接收命令的 controller 與命令集為準。

03h 讀 CAFS、NAFS 與 FRS1～7；04h 讀 NSID 清單及首筆 FFFFFFFFh 的溢位標記；05h 讀各 Opcode 的 CSUPP、effects、CSE／CSER 與 CSP。

2. 如何選擇與確認

先查 00h 支援表及相關 Identify 能力。Firmware 的 slot 數與唯讀限制由 Identify.FRMW 提供，不能只靠 03h 中非零字串的數量推算。

先根據問題選 Log：更新韌體後比較 03h 與 Identify.FR；收到 namespace 通知後讀 04h，再查 Identify；執行管理命令前讀 05h，完成後重查可能被改變的能力。

例如 NAFS=2 只表示 slot 2 等待適用的 CLR 啟用，不表示目前已從 slot 2 執行。04h 出現 NSID=7 也只指出有變更，不能單憑清單判斷它被 Format 或刪除。

3. 比較時要保留的條件

各次 Get 的錯誤與 Log 所描述的事件分開。不存在支援的 LID 回 1/09h；非法已定義參數依 Get 規則回 0/02h，不能把空 slot 或空變更清單本身當成失敗。

核對 active slot 與 FR、變更清單與新的 Identify，以及 CSUPP 與合法命令行為。每一組對照有不同目的，不要求三張 Log 的數值彼此相同。

1. 差別在哪裡

Self-test scope 受 DSTO.SDSO 等能力影響；PEL 屬於 subsystem；81h 的 NSID 則用來区分 subsystem 與 namespace sanitization target。查詢的 controller 不一定就是事件影響的全部範圍。

06h 先讀 DSTOS，再解釋進度與結果有效位；0Dh 先建立或取得 reporting context，再依事件長度走訪；81h 先看 SSTAT，再使用 SPROG 及相關結果欄位。

2. 如何選擇與確認

讀 OACS 的 Self-test 能力、LPA 的 PEL 能力，以及 SANICAP／namespace Sanitize 能力，再確認 LID06h、0Dh、81h 受支援。Log 可讀不代表任意操作方法都可用。

例如 Sanitize 命令完成後，持續查 81h 判斷背景操作；Self-test 結束後讀 06h 最新有效結果；要追查先前重設或管理操作，才到 PEL 找支援的事件。

Get 成功表示讀取成功，不表示 Self-test 通過或 Sanitize 成功。PEL 沒有某筆事件，也要先確認事件支援、記錄條件與保存範圍。

3. 比較時要保留的條件

不支援的 LID 回 1/09h；PEL context 順序錯誤可能回 Command Sequence Error（0/0Ch）。操作本身失敗要看其專用 Log 狀態，不能替本次成功 Get 改成失敗 CQE。

CQE

Completion Queue Entry，佇列中的完成項目

以操作目標、時間及最新結果交叉比對。不得將舊 Self-test 結果或上次 Sanitize 成功，當成目前這次作業已成功的證據。

1. 差別在哪裡

先辨認管理對象：Endurance Group 使用 ENDGID，Predictable Latency 針對 NVM Set；Lockdown 依選擇與支援範圍，Boot Partition 透過 controller 查詢，Media Unit 則反映 domain 或 subsystem 資源。

09h 看警告、spare 與壽命計數；0Ah／0Bh 看 Set 的 latency 狀態及事件集合；14h 看禁止的 Opcode／FID；15h 看分割區識別與保護狀態；10h 看 Media Unit 識別、歸屬及狀態。

FID

Feature Identifier，功能識別碼

2. 如何選擇與確認

先查 00h 及相關 Identify 能力。主要 LID 為 09h、0Ah／0Bh、14h、15h、10h；同一個 LSI 在不同 LID 的意義可能不同。

由待回答的問題選 LID，再由 Identify 建立資源 ID 的對應，最後依該 Log 的參數與結構解碼。例如要查 group 3 的健康狀態，LSI 應選 ENDGID=3，而不是隨手填 NSID。

成功回覆只描述選定對象。例如一個 group 的警告不能推論成全部 namespace 都有相同媒體故障；Lockdown 列出禁止項目，也不是那些命令的執行歷史。

3. 比較時要保留的條件

不支援的 LID 與非法資源選擇須分開處理。前者是 1/09h；後者依該 Log 的已定義參數與專用 Status 判斷，不能一律改成 Invalid Namespace。

核對資源歸屬、Log 狀態及實際功能。例如被禁止的 FID，應與 Lockdown 設定一致；Media Unit 狀態則要連同 namespace 所依賴的資源判斷。

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

Figure 209 列出 controller、namespace、domain、subsystem 等範圍，但個別欄位也可能有更具體的定義。讀完整張表後，仍要核對該 LID 的例外。

用 LSUPP 確認 Log 支援，再查 LPA、multi-domain 能力，以及該 LID 是否使用 CSI 或 UUID 選擇。這些能力決定哪些查詢組合有效。

controller 或 subsystem scope 的 Log，一般使用 NSID=0 或 FFFFFFFFh；LSI、LSP、CSI 與 UIDX 各有獨立用途。不能把 LSI 當成 NSID 的延伸位元。

2. 查詢順序與回覆判讀

先寫出要查的物件，例如某 controller、ENDGID=3 或某 sanitization target，再把它映射到正確欄位。其餘未定義欄位依 Reserved 規則填寫。

合法查詢回傳所選範圍的資料。例如 aggregate SMART 與某 group 的耐久度是不同範圍，不能複製同一份資料後標成每個 namespace 的獨立統計。

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

依共同規則，controller 或 subsystem scope 的 Log 若指定 0／FFFFFFFFh 以外的 NSID，須回 Invalid Field（0/02h）。其他 scope 則按各 LID 與 NSID 規則處理。

將命令中的選擇欄位、Identify 的資源對應與回傳內容一起保存，才能確定比較的是同一物件。

先查該 LID 的 scope，而不是看到 NSID 非零就認定回覆是 namespace 專屬資料。

1. 操作前先準備什麼

Offset 是 Log 內的位置，不是 Host buffer 位址。OT=0 使用 byte offset；OT=1 使用該 Log 定義的 entry index，兩種單位不能混算。

LPA.LPEDS 確認延伸長度與 offset，目標 LID 的 IOS 確認 index offset；另依 MDTS 與此 Log 的長度規則選擇每次傳輸量。

NUMD=(NUMDU<<16)|NUMDL，通常傳輸 bytes=4×(NUMD+1)。LPOU／LPOL 組成 64-bit offset；byte offset 要 Dword 對齊。某些 Log 另有 entry 或 header 規則。

2. 先後順序與完成條件

成功後應取得預定範圍。若要求長度超過 Log 尾端，除另有規定外，超出部分的結果未定義；不能把那些 bytes 當成 Log 的延伸資料。

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

Offset 大於 Log 大小，或不支援 IOS 卻使用 OT=1，須回 0/02h。byte offset 低兩位非零時，controller 可回 0/02h，也可依低兩位為零處理；不能把這個允許選擇寫成唯一錯誤結果。

核對總長度、各段 offset／NUMD、generation 或 reporting context。涵蓋完整與同一份快照，是兩個都要成立的條件。

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

LSI 的意義由 LID 決定；UIDX 從 UUID List 選擇適用定義；RAE 則影響這次讀取所對應的非同步事件。不是所有 Log 都使用三者。

先看該 LID 是否定義 LSI，以及 Get Log Page 是否支援 UUID 選擇。RAE 是否有實際作用，則要看該事件如何確認與清除。

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

LSI 在 CDW11 bits31:16；UIDX 在 CDW14 bits6:0，0 表示不指定 UUID；RAE 在 CDW10 bit15。UIDX 是索引，不是 UUID 的數值本體。

先固定目標與 UUID 定義，再決定是否要保留事件以繼續取樣。若需要分段讀取與事後確認，保存每次 RAE，並遵守該 Log 的特定確認方式。

RAE=1 的成功讀取保留對應事件；RAE=0 的成功讀取依規則清除。若命令未成功，事件必須保留，不能因 Host 已嘗試讀取就視為確認。

3. 判讀時要保留的條件

非法 UUID 選擇依 §8.1.31 回 Invalid Field（0/02h）；LSI 非法則按該 LID 定義處理。不能用改 RAE 的方式修正錯誤的資源 ID。

核對 LSI 的目標、UIDX 對應資料及事件是否仍 pending。讀取相同 bytes 但 RAE 不同，後續通知行為可能不同。

1. 先保留哪些證據

一致性判斷由各 Log 提供的機制決定。Telemetry 有 generation，PEL 有 reporting context；沒有此類機制的動態 Log，不能自行假設跨命令原子快照。

先確認支援的 Log 結構與版本，再找 generation、總長度、可用狀態或 context action。不能只查看 Get Log Page 的公共欄位。

Telemetry 記錄 TCDGN／相關 generation 及資料區邊界；PEL 記錄 context、TLL、事件長度與版本。每段同時保存 offset、length 及取得時間。

2. 依什麼順序排除原因

先看 generation 或 context 是否在整段讀取期間保持一致，再檢查解析器。

先取得 header，再按同一擷取或 context 讀取；必要時重讀 header。若前後 generation 改變，應重新取得一致資料，或明確標示無法證明一致，不能只換掉最後一份 header。

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

例如最初 TCDGN=10、最後=11，兩次 Get 都成功仍不足以證明中間所有 chunks 來自第 10 代。成功的分析結果必須連同一致性證據保存。

內容改變不一定產生錯誤 CQE；動態更新本身可以合法。PEL 的非法 context 操作則可能得到 0/0Ch，應和資料版本改變分開判斷。

將 header、每段資料及查詢順序當成一組證據，不能拿最後讀到的 capability 或 generation 回頭替所有舊 chunks 背書。

1. 機制與適用範圍

Error Information 以 controller 為範圍；PEL 保存 subsystem 的支援事件，並透過 reporting context 提供報告。兩者的容量與讀取生命週期不同。

Error entries 依新到舊排列，ECNT 識別每次錯誤。PEL 依 event header 的 EHL、EL、ET、ETR 走訪，不能假設每筆固定 64 bytes。

2. 用操作與結果理解

Error Information 的容量由 ELPE+1 決定；PEL 先看支援能力、報告 TLL、事件數與最大容量資訊。不能把 SMART 累計值當成目前 buffer 的長度。

取樣時記錄有效 entries 與首尾識別，再於後次取樣找重疊範圍。若最舊紀錄已不在可讀範圍，標示歷史缺口，不能補造它的內容或順序。

Error Log 已滿又新增 entry 時，規範建議插入新 entry 並丟棄最舊 entry。PEL 是有限的持續歷史，讀完整份報告也不等於讀到裝置全部生命週期事件。

3. 容易誤判的地方

容量用完不會使合法 Get 自動回失敗；應檢查回覆內容與各 Log 的保存規則。只有查詢參數或 context 不合法時，才依相應 Status 處理。

ECNT／SMART 的累計變化與目前筆數可能不同；應以容量及保留規則解釋，不能要求每次取樣都仍含所有舊紀錄。

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

保留規則可能適用整張 Log，也可能只適用其中某個欄位。多 controller 或 multi-domain 配置還要先確認重設影響哪些範圍。

讀各 Log 的保留敘述與 Reset 章節。Figure 209 的 Restore to Default Content 指製造預設內容的恢復，並不是「遇到任何 Reset 就清空」的能力位。

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

典型比較是 Error Information entries、其 ECNT、SMART 累計值、即時溫度、PEL 事件及 PEL context。這六種資訊即使相鄰，也不能套用同一保留結論。

先取得同一對象的前置快照，執行指定重設，恢復查詢後再讀。記錄中間是否同時發生 Firmware Activation、Format 或出廠配置恢復，避免把多個原因混成一個。

Error entries 在 CLR 與 Power Cycle 後建議清除，但 ECNT 持續；SMART 生命週期資訊原則上跨 Power Cycle 保留，個別欄位另有例外；PEL 事件的持續性不能套到 reporting context。

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

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

比較前後值本身沒有新的 Status。如果恢復後 Get 失敗，先檢查 controller 是否 Ready、選擇欄位與 context 是否有效，不能將查詢失敗解釋成內容已被清零。

以欄位的有效條件與單位比較，而不是要求整個 buffer 完全相同。累計保留與目前狀態重新取樣可以同時成立。

先確認是在比較內容保留，還是在比較一個已失效的 context 或未完成查詢。

1. 先保留哪些證據

固定接收介面、controller、CSI、UUID 選擇及配置時間。尤其 CC.CSS=110b 時，尚未啟用的命令集會被視為不支援。

一起保存 LSUPP、IOS、CSUPP、Identify 的功能位與 FID19h 設定。不要拿 LID 的支援位去判斷任意 Opcode，也不要反過來混用。

測試命令保留 LID 或 Opcode、NSID、CSI、LSP、LSI、OT、長度及資料指標。取得 CQE 後再讀 SCT／SC，而不是只記一個工具錯誤訊息。

SCT

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

2. 依什麼順序排除原因

先確認兩份證據來自同一介面與同一命令集配置，這通常比先懷疑韌體更能排除誤判。

先構造符合能力、scope 及狀態的合法命令，再執行並核對結果。若失敗，逐項排除非法參數、被 Lockdown 禁止、namespace 未就緒及配置變更。

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

在同一穩定配置下，明確宣告支援卻對合法請求回不支援，才形成需要追查的矛盾；合法的限制性 Status 不能直接當成不支援。

Get 不支援 LID 使用 1/09h；不支援 Opcode 使用 0/01h；0/02h 通常需要回頭檢查參數。保留規範的專用例外與多重錯誤選擇，不能只比一個預期數字。

比較內容、行為與時間關係三者。若韌體已啟用新版本，應先重讀宣告，不能用舊表要求新 controller 行為。

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

Admin Opcode 與 I/O Opcode 使用不同區域；I/O 區還要選對命令集。CSP 可以同時表示多種 scope，因為實際參數可能決定不同影響對象。

先讀 Identify Controller 的 LPA.CSES（Figure338 bit1），確認是否提供 LID05h，再固定命令集與 UUID 選擇。這個位元只表示能力 Log 可讀，Log 裡各 Opcode 是否受支援仍要逐筆查 CSUPP。CSP=0 則表示未回報 scope，不能解成「不影響任何物件」。

Figure216 先決定 entry 位置：Admin 使用 4×Opcode，I/O 使用 1024+4×Opcode，單位都是 bytes。Figure217 再定義這 4 bytes 中的 CSUPP、LBCC、NCC、NIC、CCC、CSE、CSER、USS 及 CSP。例如 Admin Opcode02h 是 Get Log Page，NVM I/O Opcode02h 卻是 Read；即使編碼相同，也不能查同一筆 entry。

2. 查詢順序與回覆判讀

先找到正確 entry，再依 CSE／CSER 的建議協調其他工作。Host 支援非零 CSER 值時，使用其放寬建議；不支援時回到 CSE。命令完成後，重新查詢可能改變的能力或清單。

例如 NIC=1 表示命令可能改變 namespace 數量或多個 namespace 的能力，不表示這次呼叫一定新增一個 namespace。CSUPP=0 時，其餘 entry 欄位須為零。

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

讀表失敗依 Get Log Page 處理；實際命令失敗則依該命令 Status。CSE 的建議不能任意提高成一個固定的強制錯誤碼。

將 effects 與操作前後 Identify、清單及使用者資料影響交叉比對。CSUPP 與 Identify 宣告應一致，但實際效果仍須依本次參數判斷。

先確認 Admin 或 I/O 區，再核對 Opcode、byte offset 與成功的查詢 CQE。Log 中資料的起點、分段 buffer 的起點，以及 entry 內的 bit 位置是三種座標；把任一種誤當另一種，都可能讀到別的命令或欄位。