NVMe · Q1–328
Q44–Q53
Identify 提供多種查詢結構。先確定要查哪個物件、需要哪一種資訊，再選擇 CNS、CSI、NSID 及其他欄位。本冊分別說明能力、目前配置與清單變更，讓你知道不同回覆如何互相補充，以及哪些差異才可能構成矛盾。
每個問題都接著完整解說，依內容帶讀欄位、比較機制或追蹤流程。先看本冊總覽，再沿問題閱讀；必要條件與正常路徑直接顯示。所有數字案例均為教學假設；Status 以 SCT/SC 表示，代碼後的 h 代表十六進位。
每個 CNS 回答的問題不同。namespace 已配置，只表示它存在，不能直接推論目前這個 controller 已能存取它。
| 想知道什麼 | 查詢入口 | 回覆如何使用 |
|---|---|---|
| controller 宣告的能力 | CNS=01h | 讀取 OACS、ONCS、MDTS 等欄位，並依各欄位的有效條件判讀 |
| 目前可存取的 namespaces | CNS=02h | 取得此 controller 的 Active List；這不是全部已配置 namespace 的清單 |
| 已配置的 namespaces | 支援 Namespace Management 時用 CNS=10h | 清單可包含未 attach 到此 controller 的 namespace |
| 單一 NVM namespace 的格式 | CNS=00h；需要時加 CNS=05h、CSI=00h | NSZE／NCAP、FLBAS、LBAF 與 PI 格式共同解讀 |
| 不依賴命令集的 namespace 屬性 | CNS=08h | 使用此結構解讀共通屬性，不要套用 NVM 特定 LBA 格式結構的欄位位置 |
舉例看懂：假設 Allocated List={1,2}，而目前 controller 的 Active List={1}。這表示 namespace 2 不在此 controller 的 Active List 中，但不能據此判定它已被刪除。下一步應確認附加關係及適用狀態，並保留 controller 身分與查詢時間，讓前後資料可以正確比較。
來源：Base 2.4 §5.2.14.1 · Base 2.4 §5.2.14.2.1 · Base 2.4 §5.2.14.2.2–5.2.14.2.19, 5.2.14.3.1–5.2.14.3.2 · NVM Command Set 1.3 §4.1.5.1–4.1.5.4 · Base 2.4 §5.2.24–5.2.25, 8.1.17
Identify Controller 描述 controller 的能力與屬性；Identify Namespace 描述指定 namespace 的格式及容量；Active List 則列出目前可經由這個 controller 使用的 namespace。先用 Active List 取得可存取的 NSID，再逐一讀取格式與容量；控制器能力則由 Identify Controller 補足。不能只讀到 Controller.NN，就認定 NSID 從 1 到 NN 全都存在，而且全部可存取。
解讀數值前，先確認欄位的資料型態：CNS 選擇資料結構，CSI 選擇命令集，bitmap 的各位元代表不同能力，index 則指出清單中的某一筆。例如讀取 LBA 格式時，先從 FLBAS 解出索引，再讀取對應的 LBAF 描述；不能把 FLBAS 的原始數字直接當成 byte 數。知道數值用來選擇什麼，比單獨背下十六進位值更容易正確運用。
要觀察管理操作的結果，必須等操作成功後再查詢：Create 成功後查 Allocated List，Attach 成功後查目標 controller 的 Active List。如果另一個管理者同時修改配置，兩份清單可能來自不同時點。先確認查詢順序及對象，再判斷 controller 是否漏了更新，才能避免把正常的時間差當成錯誤。
Identify Controller 用來了解 controller 支援哪些能力；Identify Namespace 則用來了解指定 namespace 的容量、格式及資料保護設定。先分清楚查詢對象，才知道該讀哪一組欄位。
Identify Controller 以接收命令的 controller 為查詢入口。Namespace 資料則要搭配 NSID、CNS 及 CSI，確認要查的是哪個 namespace，以及哪一種資料結構。
Controller 看 SN、MN、FR、MDTS、OACS、ONCS、LPA、SQES／CQES；NVM Namespace 看 NSZE／NCAP／NUSE、FLBAS／LBAF、MC／DPC／DPS、原子性及群組識別。
基本查詢入口是 CNS01h 的 Controller 資料，以及 CNS00h 的 NVM Namespace 資料。CNS05h／06h 查詢命令集特定的補充結構，CNS08h 則提供不依賴特定命令集的 Namespace 資料。
先查 Controller 資料及 Active Namespace ID List，再逐一查詢各 namespace 適用的資料結構。計算容量時，使用目前選定的 LBA format，將 block 數換算成 bytes。
Identify 回傳 4096-byte 結構與成功 CQE。例：NSZE=8192、LBADS=12，邏輯位址空間為 8192×4096=32 MiB。
不支援 CNS 時，回報 Invalid Field（0/02h）；namespace 所屬命令集不支援該 CNS 時，回報 Invalid I/O Command Set（1/2Ch）。至於 NSID 是否合法，則依該 CNS 的使用規則判斷。
controller 宣告支援某個命令，不代表每個 namespace 都具備適合的格式，或目前都能由此 controller 存取。因此，驗證時必須同時確認 controller 能力與目標 namespace 的條件。
來源：Base 2.4 §5.2.14.1 · Base 2.4 §5.2.14.2.1 · NVM Command Set 1.3 §4.1.5.1–4.1.5.4 · Base 2.4 §5.2.14.2.2–5.2.14.2.19, 5.2.14.3.1–5.2.14.3.2 · Base 2.4 §3.7.1–3.7.4 · Base 2.4 §4.2.3 · Base 2.4 §5.2.13.1.2 · Base 2.4 §5.2.2 · Base 2.4 §5.2.13.1.14 (header, reset, hardware, Set Feature events)
來源：Base 2.4 §5.2.14.1 · Base 2.4 §5.2.14.2.1 · NVM Command Set 1.3 §4.1.5.1–4.1.5.4 · Base 2.4 §5.2.14.2.2–5.2.14.2.19, 5.2.14.3.1–5.2.14.3.2 · Base 2.4 §3.7.1–3.7.4 · Base 2.4 §4.2.3 · Base 2.4 §5.2.13.1.2 · Base 2.4 §5.2.2 · Base 2.4 §5.2.13.1.14 (header, reset, hardware, Set Feature events)
這三種查詢分別回答：哪些 namespace 可由此 controller 使用、哪些 namespace 已經配置，以及某個 namespace 有哪些識別資料。它們不是同一份清單的不同名稱。
Active List 反映此 controller 可使用的 namespace；Allocated List 可以包含已配置但尚未附加的 namespace。Descriptor List 則不是 namespace 名單，而是單一 NSID 的識別屬性集合。
查詢 ID List 時，NSID 是分頁的起點，回傳清單列出大於該起點的 ID。Descriptor 則透過 NIDT、NIDL、NID 描述識別資料，例如 EUI64、NGUID、UUID 或 CSI；它不是用來列出其他 namespace。
CNS02h 查詢 Active List，CNS10h 查詢 Allocated List，CNS03h 查詢 Namespace Identification Descriptor List。使用 Allocated List 查詢前，還要確認 Namespace Management 支援能力。
讀取 ID List 時，先以 NSID=0 查詢，再依回傳的遞增 ID 繼續讀取下一批。查詢 Descriptor List 時，NSID 改為指定要查的 namespace。因此，同一個 NSID 欄位在這兩類查詢中的用途不同。
例如 Allocated={1,3,8}，而 Active={1,8}，表示 namespace 3 已配置，但目前不在此 controller 的 Active List 中。這個差異本身不代表 namespace 3 已損壞。
CNS02h 或 CNS10h 若將起點設為 FFFFFFFEh 或 FFFFFFFFh，必須回報 Invalid Namespace or Format（0/0Bh）。若問題是 controller 不支援所選 CNS，則回報 0/02h。
跨時間比對 namespace 時，使用 Descriptor 提供的穩定識別資料，不要假設 NSID 永遠不變。如果分頁讀取期間發生配置變更，則需重新取得彼此一致的清單內容。
來源：Base 2.4 §5.2.14.2.2–5.2.14.2.19, 5.2.14.3.1–5.2.14.3.2 · Base 2.4 §3.2.1 · Base 2.4 §3.7.1–3.7.4 · Base 2.4 §4.2.3 · Base 2.4 §5.2.13.1.2 · Base 2.4 §5.2.2 · Base 2.4 §5.2.13.1.14 (header, reset, hardware, Set Feature events)
這些資料分別回答三個問題：哪些 controller 與 namespace 有存取關係、應使用哪一套廠商定義解讀資料，以及哪些 I/O command sets 可以同時使用。
Controller List 描述 controller 的名單或附加關係。UUID List 則讓 Host 選擇廠商特定資料所使用的定義；它與 namespace 自身的 UUID Descriptor 是不同資訊。
CNTID 的用途取決於 CNS，可能是清單的查詢起點，也可能指定目標 controller。UIDX=0 表示不指定 UUID。CNS1Ch 回傳的每個 vector，則表示一組可同時使用的 CSI。
CNS12h 查某 namespace 附加的 controllers，13h 查 subsystem I/O controllers，17h 查 UUID List，1Ch 查 command-set combinations。
先依查詢目的選擇 CNS，再設定它使用的選擇欄位。若從 CNS1Ch 選定一組命令集組合，設定 FID19h 時，IOCSCI 要填該組合的索引，不能直接填入 CSI bitmap。
Controller List 回傳 controller 識別值及數量；UUID List 回傳依規定順序排列的 entries；命令集組合 vectors 則列出 Host 可選的配置。查到某個組合，不表示它已自動啟用。
不支援 CNS 時，回報 0/02h；CNS12h 使用 NSID=FFFFFFFFh 時，也回報 0/02h。UUID 選擇錯誤則依 §8.1.31 判斷，不能一律解釋為 namespace 不存在。
先核對 CNTID 與 NSID 在所選 CNS 中各自的用途，不要把 Controller List 當成 Active Namespace ID List。設定命令集組合後，另以 FID19h 的 Current 值確認是否選到預期的 vector。
來源：Base 2.4 §5.2.14.2.2–5.2.14.2.19, 5.2.14.3.1–5.2.14.3.2 · Base 2.4 §5.2.14.1 · Base 2.4 §8.1.31.1–8.1.31.2 · Base 2.4 §5.2.30.1.18 · Base 2.4 §3.7.1–3.7.4 · Base 2.4 §4.2.3 · Base 2.4 §5.2.13.1.2 · Base 2.4 §5.2.2 · Base 2.4 §5.2.13.1.14 (header, reset, hardware, Set Feature events)
這些 Identify 資料用來建立資源歸屬關係。NVM Set、Endurance Group、Domain 與 controller 分別描述不同的管理對象，不能當成同一層的物件。
每種清單都有自己的 ID、容量或資源欄位。本題著重查明它們的關係與屬性，不涉及修改容量配置或虛擬化資源。
先查 CTRATT 的相關能力與 OACS.VMS；CNS04h、19h、18h、14h／15h 分別對應 Set、Endurance Group、Domain、Primary／Secondary Controller。
NVM Set Attributes 透過 ENDGID 表示所屬 Endurance Group；Namespace 資料則提供 NVMSETID 與 ENDGID。Domain entry 的 DID、TDC、UDC 用來描述識別及容量；Secondary Controller entry 的 SCID、PCID、狀態及 VQ／VI 數量，則用來描述 controller 關係與資源。
先由 namespace 的群組識別資料，查出對應的 NVM Set 與 Endurance Group。再利用 Domain List 確認容量歸屬，並透過 Primary Controller Capabilities 及 Secondary Controller List，了解 queue 與 interrupt 資源的配置。
成功查詢後，應取得能互相對應的 ID 與屬性。但欄位為零不一定表示資源數量為零；必須先確認相關能力受支援，而且這個欄位在目前配置下有效。
不支援的 CNS 回報 0/02h。某些清單查詢若將起點設在目前最大 ID 之後，則會回傳空清單；不能只因沒有 entry，就要求 controller 回報錯誤。
比對清單中的資源數、Number of Queues，以及實際可建立的 QID 與可用 IV。同時分清楚 Primary Controller 宣告的能力，與 Secondary Controller 已獲配置的資源，兩者不一定是相同數量。
先確認查詢是送到哪個 Primary Controller，再確認清單的查詢起點是否符合預期。
來源：Base 2.4 §5.2.14.2.2–5.2.14.2.19, 5.2.14.3.1–5.2.14.3.2 · Base 2.4 §8.2.7 · Base 2.4 §5.2.14.2.1 · NVM Command Set 1.3 §4.1.5.1–4.1.5.4 · Base 2.4 §3.7.1–3.7.4 · Base 2.4 §4.2.3 · Base 2.4 §5.2.13.1.2 · Base 2.4 §5.2.2 · Base 2.4 §5.2.13.1.14 (header, reset, hardware, Set Feature events)
Identify 失敗時，必須先看哪個選擇欄位不符合使用規則。CNS、CSI、NSID 與 UUID Index 的用途不同，不能將所有失敗都歸為 Invalid Namespace。
相同的 NSID 或 CSI，用在不同 CNS 時，合法性可能不同。因此，測試某個欄位前，必須固定 CNS 及相關前提。
CNS 不使用 CNTID 時，Host 將它清零，controller 忽略它。對不使用的 CSI，規範建議 Host 清零，並建議 controller 忽略；若 Host 填入非零值，controller 也可以回報 Invalid Field。
不支援 CNS 時回報 0/02h；namespace 所屬命令集不支援該 CNS 時回報 1/2Ch；CNS02h／10h 使用非法的末端起點時回報 0/0Bh。如果命令使用 UUID 選擇，而 UIDX 指向不支援該資料的 UUID、全零 UUID 或 NVMe Invalid UUID，則必須回報 0/02h。CSI 的合法性則要看該 CNS 是否使用它，以及 namespace 所屬的命令集。
Figure 336 指定每個 CNS 是否使用 NSID、CNTID、CSI；UIDX 使用還受 UUID 選擇能力控制。
驗證時先固定其他選擇欄位，每次只改動待測欄位。先列出所選 CNS 的專用規則，再用通用規則補足，避免忽略例外。
有效查詢回傳 4096 bytes。例如，CNS11h 對符合定義的未配置 NSID，可以回傳全零資料；這與指定無效 NSID 而回報錯誤，是不同情況。
保留 CQE 及原命令的 CDW10、CDW11、CDW14。不同欄位錯誤都可能得到 0/02h，只有 Status 數值不足以指出是哪個參數造成失敗。
先確認這個 CNS 是否使用待測欄位。若規範要求或允許忽略該欄位，controller 沒有因它報錯，就不能直接判為漏做檢查。
來源：Base 2.4 §5.2.14.1 · Base 2.4 §5.2.14.2.2–5.2.14.2.19, 5.2.14.3.1–5.2.14.3.2 · Base 2.4 §8.1.31.1–8.1.31.2 · Base 2.4 §4.2.3 · NVM Command Set 1.3 §4.1.5.1–4.1.5.4 · Base 2.4 §3.7.1–3.7.4 · Base 2.4 §5.2.13.1.2 · Base 2.4 §5.2.2 · Base 2.4 §5.2.13.1.14 (header, reset, hardware, Set Feature events)
來源：Base 2.4 §5.2.14.1 · Base 2.4 §5.2.14.2.2–5.2.14.2.19, 5.2.14.3.1–5.2.14.3.2 · Base 2.4 §8.1.31.1–8.1.31.2 · Base 2.4 §4.2.3 · NVM Command Set 1.3 §4.1.5.1–4.1.5.4 · Base 2.4 §3.7.1–3.7.4 · Base 2.4 §5.2.13.1.2 · Base 2.4 §5.2.2 · Base 2.4 §5.2.13.1.14 (header, reset, hardware, Set Feature events)
Identify Controller 同時包含識別字串、傳輸限制及能力 bitmap。這些欄位的資料型態不同，必須各自解讀，不能全部當成一般整數。
SN 與 MN 識別 NVM subsystem，FR 描述目前啟用的韌體版本。MDTS 限制單次資料傳輸大小，OACS 則宣告選配 Admin 功能的支援能力。
CNS01h：SN bytes23:4、MN63:24、FR71:64、MDTS byte77、OACS bytes257:256。
識別字串依 ASCII 解讀，並注意尾端的空白填補。MDTS 非零時，傳輸上限為 2^MDTS×2^(12+CAP.MPSMIN) bytes；計算使用 CAP.MPSMIN，不是 CC.MPS。MDTS=0 只表示此欄位不設定上限，命令本身仍可能有其他長度限制。
先確認回傳結構及欄位位置，再依資料型態分別讀取字串、能力位及指數編碼。計算傳輸長度時，另查 CTRATT.MEM，確認 metadata 是否計入限制。
例如 MPSMIN=0、MDTS=5，傳輸上限為 128 KiB。若 MEM=0，傳送 32 個 4096-byte 資料區塊時，還要計入每塊 16-byte 的 metadata；加總後就超過 128 KiB。
超過 MDTS 的命令回報 Invalid Field（0/02h）；不支援的選配 Opcode 通常回報 0/01h。NVMe 版本較新，不代表所有選配命令都必須支援。
將 FR 與 Firmware Slot Information 中目前 active slot 的版本比對，不要誤拿尚待啟用的 slot 比較。OACS 宣告的能力，則應與 Commands Supported and Effects Log 中對應命令的支援欄位一致。
來源：Base 2.4 §5.2.14.2.1 · Base 2.4 §3.1.4 (CAP, VS) · Base 2.4 §1.4.1 · Base 2.4 §3.7.1–3.7.4 · Base 2.4 §4.2.3 · Base 2.4 §5.2.13.1.2 · Base 2.4 §5.2.2 · Base 2.4 §5.2.13.1.14 (header, reset, hardware, Set Feature events)
驗證能力時，要確認 Host 能在合法條件下使用該功能，不能只確認 Identify 的支援位為 1，就認定功能已驗證完成。
查詢與測試應針對同一 controller、命令集及 namespace 配置，並注意資料取得的時間。不同配置或不同時點的結果，不能直接當成同一狀態比較。
先查 Identify 的功能支援欄位，再確認 LPA.CSES。接著從 LID05h 選出正確的 Admin 或 I/O Opcode entry，讀取 CSUPP 與命令效果欄位。
除了 CSUPP，還要讀取 LBCC、NCC、NIC、CCC、CSE 等欄位。它們用來說明命令可能如何影響資料、能力與 namespace 清單，以及執行時有哪些限制。
先確認合法前提與支援能力，準備好參數及資源，再執行命令。完成後檢查 CQE 與實際結果，並依 effects 欄位指出的變更，重新查詢可能受影響的資訊。
宣告支援表示這項功能有合法的使用方式，不表示任何參數或任何狀態下都會成功。驗證成功時，也不能只看 CQE，還要確認命令產生了規範要求的效果。
若回報 0/01h，可能與 Opcode 支援宣告矛盾。但若回報 0/02h、Namespace Not Ready，或受到 Lockdown 限制，則應先查參數與目前狀態，不能立即判定支援宣告錯誤。
Commands Supported and Effects Log 描述命令支援能力及可能影響，不是執行歷史。某個 entry 宣告命令受支援，不表示這條命令最近曾經執行過。
先檢查拿的是 Admin 還是 I/O opcode entry，以及 CSI 是否選對。
來源：Base 2.4 §5.2.13.1.6 · Base 2.4 §5.2.14.2.1 · Base 2.4 §5.2.14.1 · Base 2.4 §3.7.1–3.7.4 · Base 2.4 §4.2.3 · Base 2.4 §5.2.13.1.2 · Base 2.4 §5.2.2 · Base 2.4 §5.2.13.1.14 (header, reset, hardware, Set Feature events)
namespace 配置改變後，Host 必須重新取得受影響的資訊，才能避免沿用舊容量、舊格式或舊的附加關係。
Create／Delete 改變 namespace 是否存在；Attach／Detach 改變 controller 是否能使用它；Format 則改變操作範圍內的資料格式。不同操作需要檢查的資料也不同。
OACS.NMS 確認管理支援；Format 還看 OACS／FNA 及 NVM 支援格式。
分別檢查 Allocated List、Active List、CNS12h 回傳的已附加 Controller List，以及 Namespace 資料中的 FLBAS、DPS、NSZE、NCAP 等欄位，不要期待每種操作都改變相同欄位。
先記錄操作前的資料，等待管理命令完成，再重新查詢受影響的清單及 namespace。尤其 Create 成功只表示 namespace 已建立，不表示它已自動附加到 controller。
Create 後，namespace 應出現在 Allocated List；Attach 後，應出現在目標 controller 的 Active List。Detach 後，它會從該 Active List 移除，但仍可能留在 Allocated List。Format 後則要檢查選定格式是否正確，不能假設 NSID 必須改變。
管理命令失敗時，不能直接假設所有資料都已更新，也不能假設完全沒有變動。先查該命令對失敗及部分完成的規則，再重新查詢實際狀態。
將管理命令結果、相關清單、Namespace 資料結構，以及適用的 Changed Namespace 通知一起比對。事件用來通知變更，不能代替 Identify 所提供的完整配置資料。
將 Changed Namespace List（LID 04h）與重新讀取的 Identify 一起檢查。前者指出哪些 NSID 曾經變更，後者提供目前配置，兩者不能互相代替。讀取 Log 時的 RAE 會影響事件確認，因此先保存原事件與清單，再進行後續查詢。
來源：Base 2.4 §5.2.14.2.2–5.2.14.2.19, 5.2.14.3.1–5.2.14.3.2 · NVM Command Set 1.3 §4.1.5.1–4.1.5.4 · Base 2.4 §5.2.24–5.2.25, 8.1.17 · Base 2.4 §5.2.13.1.6 · Base 2.4 §3.7.1–3.7.4 · Base 2.4 §4.2.3 · Base 2.4 §5.2.13.1.2 · Base 2.4 §5.2.2 · Base 2.4 §5.2.13.1.14 (header, reset, hardware, Set Feature events) · Base 2.4 §5.2.13.1.5, 5.2.13.1.14.2.6–5.2.13.1.14.2.8
來源：Base 2.4 §5.2.14.2.2–5.2.14.2.19, 5.2.14.3.1–5.2.14.3.2 · NVM Command Set 1.3 §4.1.5.1–4.1.5.4 · Base 2.4 §5.2.24–5.2.25, 8.1.17 · Base 2.4 §5.2.13.1.6 · Base 2.4 §3.7.1–3.7.4 · Base 2.4 §4.2.3 · Base 2.4 §5.2.13.1.2 · Base 2.4 §5.2.2 · Base 2.4 §5.2.13.1.14 (header, reset, hardware, Set Feature events) · Base 2.4 §5.2.13.1.5, 5.2.13.1.14.2.6–5.2.13.1.14.2.8
是否允許 Identify 資料改變，要逐欄依性質判斷。不能將整個 4096-byte buffer 一律要求完全相同，因為其中包含動態狀態及可能更新的能力。
可先分成固定身分、韌體宣告能力、持續配置與動態狀態四類。這四類資料允許改變的原因不同，因此比較時也要使用不同的判斷條件。
保存 SN／MN、namespace 穩定識別、FR、能力位、容量／格式／附加關係及動態欄位作比較基準。
FR 應描述目前已啟用的韌體；韌體更新後，MDTS 及能力位需要重新確認。NUSE 等動態數值則可能隨使用狀態改變，不能拿來當固定的裝置識別資料。
先記錄發生了哪些操作：只有 Reset 或 Power Cycle，還是同時有韌體啟用或管理配置變更。恢復後，使用相同的 CNS、NSID、CSI 查詢，再逐欄對照其保留及變更規則。
一般 Reset 並不是重新命名裝置、刪除 namespace 或執行 Format。如果重設同時啟用了新韌體，則 FR 及規範允許隨之變更的能力，不能一律要求保留舊值。
比較前後資料本身不會產生新的 CQE Status。如果重設後 Identify 失敗，應先分辨是初始化尚未完成、NSID 無效，還是 CNS 選錯，不能把所有差異都直接歸為韌體錯誤。
先用穩定識別資料確認比較的是同一物件，並保留原始 bytes。再分別處理填補空白、Reserved 欄位、動態值及真正有意義的屬性變更，避免只做逐 byte 比較就下結論。
先確認這次 Reset 是否同時啟用了待啟用的韌體，或查詢是否實際送到另一個 controller／namespace。
來源：Base 2.4 §5.2.14.2.1 · Base 2.4 §4.7.1 · NVM Command Set 1.3 §4.1.5.1–4.1.5.4 · Base 2.4 §3.7.1–3.7.4 · Base 2.4 §5.2.13.1.6 · Base 2.4 §4.2.3 · Base 2.4 §5.2.13.1.2 · Base 2.4 §5.2.2 · Base 2.4 §5.2.13.1.14 (header, reset, hardware, Set Feature events)
判定不一致時，要把能力、設定、當下狀態及命令結果連起來檢查。不能只因某個介面顯示支援，就忽略實際使用所需的其他條件。
比對前，先固定 controller、NSID、CSI、時間及配置。來自不同 controller 或不同時點的資料，可能本來就在描述不同狀態。
Identify 描述能力與屬性；Get Features 查詢設定；Log Page 則依種類提供狀態、事件或命令效果。三者用途不同，數值不相同本身不代表矛盾。
保留原 SQE、CQE、Identify 原始 buffer，以及 Get Features 使用的 SEL、Get Log Page 使用的 LID 和其他選擇欄位。尤其要分清楚讀到的是 Current 值，還是 Supported Capabilities。
第一步先確認這些資料是否來自同一 controller／namespace、同一設定期間，並且使用相同或互相對應的選擇欄位。
先確認規格版本與解碼方式，再檢查操作範圍及選擇欄位。接著確認參數合法、目前狀態允許執行，而且先後順序正確，最後才判斷結果。若仍有矛盾，可用每次只改一項條件的情境重現。
一致是指各介面符合規範定義的關係，不是回傳值必須全部相同。例如 CHANG=1 表示 Feature 可變更，Current=0 表示目前設定為 0，兩者可以同時正確。
先依原命令的 SCT／SC 決定下一步；More=1 時，再查可與命令關聯的 Error Information。如果只有 Host timeout 而沒有 CQE，則先追查命令是否提交及完成，不能直接套用某個 Status 的處理方式。
只有確認必要前提成立、資料來自同一物件，而且時間順序一致後，結果仍違反明確規定，才能提出可驗證的不符合規範結論。
來源：Base 2.4 §5.2.14.1 · Base 2.4 §5.2.13.1.6 · Base 2.4 §4.4 · Base 2.4 §5.2.12 · Base 2.4 §5.2.13.1.2 · Base 2.4 §3.7.1–3.7.4 · Base 2.4 §4.2.3 · Base 2.4 §5.2.2 · Base 2.4 §5.2.13.1.14 (header, reset, hardware, Set Feature events)
Base 的文件頁碼等於 PDF 頁碼減 26；NVM 與 PCIe 兩份規格的文件頁碼則與 PDF 頁碼相同。以下依提供的 PDF 本文列出章節、頁碼及 Figure 編號。若同一頁包含其他主題，只引用本題需要的定義，不納入 Fabrics 或 PCIe Link、封包內容。
以下連結可開啟對應的圖表教學，查閱欄位及判讀方式。每張圖保留固定的教學位置，方便之後反覆查詢。
NVM-Express-Base-Specification-Revision-2.4-Ratified-2026.07.31.pdfNVM-Express-NVM-Command-Set-Specification-Revision-1.3-Ratified-2026.07.31.pdfNVM-Express-NVMe-over-PCIe-Transport-Specification-Revision-1.4-Ratified-2026.07.31.pdf