NVM Express Base 2.4 NVM Command Set 1.3 NVMe over PCIe Transport 1.4
每張原圖都有用途、欄位和判讀例子。例子中的數值用於說明，不代表你的裝置設定；原文另有條件時，依該欄位與命令定義判斷。
用瀏覽器「在頁面中尋找」搜尋欄位、FID、LID、CNS 或 Figure。bit／byte 位置沿用原圖：bit 是位元，byte 是 8 bits，Dword 是 4 bytes；index 是第幾筆，offset 是相對起點的偏移，須看當處使用的單位。
FID Feature Identifier，功能識別碼
LID Log Page Identifier，紀錄頁識別碼
CNS Controller or Namespace Structure，選擇Identify回傳結構 FID（Feature Identifier）選擇功能；LID（Log Page Identifier）選擇紀錄頁；CNS（Controller or Namespace Structure）選擇 Identify 回傳的資料結構。
從情境練習開始 直接查圖表 先跟著一個情境讀規格
以下回傳資料均為教學假設。先看需求與已知條件，再沿閱讀路線找到相關欄位，接著一起判讀結果。完整解說直接顯示，來源細節可另外展開。
最多還能建立幾個 namespace？ namespace 存在，為什麼這個 controller 看不到？ 重開機後 NSID 改了，還是同一份資料嗎？ 容量是位址範圍、可配置量，還是已使用量？ 128 KiB 資料為什麼可能超過 MDTS？ Dataset Management 的限制是 0，代表不支援嗎？ 有 LID 編號，就一定能讀那張 log 嗎？ 練習 01 最多還能建立幾個 namespace？管理程式把 NN 當成可建立的 namespace 數量。你要怎麼修正它，並回答「現在還能建立幾個」？
模擬回傳與已知條件
OACS.NMS=1；NN=1000；MNAN=16；MAXCNA=8。
完整 Allocated Namespace ID list 有 10 筆；此 controller 的 Active list 有 6 筆。剩餘容量與建立參數尚未查詢。
沿著欄位一步步理解
查詢次序： Identify CNS=01h → CNS=10h 完整已配置清單 → CNS=02h 此 controller 的活動清單；必要時再查容量與 Namespace Management 參數。
推導 1 NN 是有效 NSID 的最大值；MNAN 才是此例的 subsystem namespace 數量上限。NSID 可以不連續，所以最大編號 1000 不代表存在 1000 個 namespace。MAXCNA=8 則限制此 I/O controller 可附接的數量，不能拿來取代 MNAN。
NSID Namespace Identifier，邏輯儲存空間識別碼 推導 2 只看數量，上限還有 16−10=6 個名額；此 controller 的附接名額還有 8−6=2 個。建立與附接是不同步驟，建立第 3 個新 namespace 不等於也能把它附接到這個 controller。
推導 3 這不是保證能成功建立 6 個：每個 namespace 所需容量、格式、資源及同時發生的管理操作仍會影響結果。若 MNAN=0，NN 仍是可配置 namespace 數量的上限依據；例如 NN=1000 不能解成可建立無限個 namespace。
完整原文定位 Base 2.4 · §5.2.14.2.1 · Figure 338 · Identify – Identify Controller Data Structure, I/O Command Set Independent · 文件頁 353, 370, 378 · PDF 379, 396, 404 Base 2.4 · §3.2.1 · 文件頁 78–80 · PDF 104–106 Base 2.4 · §5.2.14 · Figure 336 · Identify – CNS Values · 文件頁 338–339 · PDF 364–365 Base 2.4 · §5.2.25 · Figure 446 · Namespace Management – Command Dword 10 · 文件頁 446–447 · PDF 472–473 NVM Command Set 1.3 · §4.1.6 · Figure 134 · Namespace Management – Host Specified Fields · 文件頁 112–113 · PDF 112–113 回情境索引 接著看其他情境
練習 02 namespace 存在，為什麼這個 controller 看不到？盤點程式在 subsystem 找到 NSID=27，卻沒有對應的可存取 namespace。這足以判定資料遺失嗎？
模擬回傳與已知條件
NN=100；CNS=10h 回傳 [2, 9, 27]；CNS=02h 回傳 [2, 9]；兩張清單均已讀完。
裝置支援 Namespace Management；查詢期間沒有變更 namespace 配置。
沿著欄位一步步理解
查詢次序： Identify CNS=01h 確認範圍與能力；分別讀 CNS=10h、02h；若需確認附接對象，使用 CNS=12h、NSID=27。
推導 1 27 在有效範圍，而且出現在 Allocated list，表示該 namespace 已存在。它不在此 controller 的 Active list，只能得出它未附接到此 controller；不能說它不存在，更不能說媒體上的資料已遺失。
推導 2 CNS=12h 回答該 namespace 附接到哪些 controller。這可區分「附接在別處」與「已建立但尚未附接」；是否應改配置是後續決策，不是盤點查詢本身的結論。
推導 3 大量 namespace 時，每次清單最多容納 1024 個 NSID。下一次以最後一個非零 NSID 作為起點，取得大於該值的項目；不能只讀第一頁就把後面的 namespace 判成不存在。
完整原文定位 Base 2.4 · §3.2.1 · 文件頁 78–80 · PDF 104–106 Base 2.4 · §5.2.14 · Figure 336 · Identify – CNS Values · 文件頁 338 · PDF 364 Base 2.4 · §5.2.14.2.2 · 文件頁 387 · PDF 413 Base 2.4 · §5.2.14.2.9 · 文件頁 395 · PDF 421 Base 2.4 · §5.2.14.2.11 · 文件頁 395 · PDF 421 回情境索引 練習 03 重開機後 NSID 改了，還是同一份資料嗎？開機前的 NSID=3，開機後變成 NSID=9。你會比容量、NSID，還是另一種識別資訊？
模擬回傳與已知條件
前後 CNS=03h 的非零 Namespace UUID 相同；兩次都來自同一個已確認的 subsystem。
容量相同，但尚未讀取使用者資料。
沿著欄位一步步理解
查詢次序： Identify CNS=03h，分別指定當時 NSID；依 NIDT、NIDL 解析識別描述子，保留識別值。
推導 1 NSID 是命令選擇 namespace 的編號，可能跨斷電改變。Namespace UUID 是用來辨識 namespace 的資訊；本例相同的 UUID 支持它是同一個 namespace，不能只因 NSID 改變就視為新建物件。
推導 2 解析時先看 NIDT 指定識別種類，再依 NIDL 取出該種類的 bytes；不要把整個描述子連同表頭直接當作 UUID 比較。若改用 NGUID 或 EUI64，也要考慮 UIDREUSE 所描述的重用特性。
推導 3 識別相同不代表內容從未變動，也不能證明每個 LBA 都完整。若問題改成「資料有沒有改過」，需要另訂資料校驗方法；如果沒有可用的唯一識別資訊，僅靠相同容量不足以下定論。
LBA Logical Block Address，邏輯區塊位址 完整原文定位 Base 2.4 · §3.2.1 · 文件頁 80 · PDF 106 Base 2.4 · §5.2.14.2.3 · Figure 342 · Identify – Namespace Identification Descriptor · 文件頁 388 · PDF 414 Base 2.4 · §5.2.14.2.8 · Figure 346 · Identify – I/O Command Set Independent Identify Namespace Data Structure · 文件頁 391–394 · PDF 417–420 回情境索引 練習 04 容量是位址範圍、可配置量，還是已使用量？容量報告把 NSZE、NCAP、NUSE 三個數字相加。請用這份回傳值解釋為什麼不對。
模擬回傳與已知條件
目前 LBAF 的 LBADS=12、MS=0；NSZE=8192、NCAP=4096、NUSE=1024。
這是支援 thin provisioning 的 NVM namespace，數值有效，沒有不可存取狀態造成的清零。
沿著欄位一步步理解
查詢次序： Identify CNS=00h、目標 NSID → 由 FLBAS 選取 LBAF → 同時讀 NSZE、NCAP、NUSE。
推導 1 LBADS=12 表示每個 LBA 的資料大小是 2^12=4096 bytes。NSZE=8192 給出 32 MiB 的可定址資料範圍，合法 LBA 是 0 到 8191，不是到 8192。
LBA Logical Block Address，邏輯區塊位址 推導 2 NCAP=4096 是最多可配置的 logical blocks，換算為 16 MiB；NUSE=1024 是目前已配置的 logical blocks，換算為 4 MiB。它們從不同角度描述同一 namespace，並不是三塊可相加的獨立空間。
推導 3 NUSE 也不是檔案系統的已用容量。檔案刪除、deallocation、控制器的配置粒度與更新時機可能使兩者不同；要回答檔案還能存多少，需要檔案系統資訊，而不是改寫 NSZE 的意義。
完整原文定位 NVM Command Set 1.3 · §4.1.5.1 · Figure 123 · Identify – Identify Namespace Data Structure, NVM Command Set · 文件頁 85–87 · PDF 85–87 NVM Command Set 1.3 · §4.1.5.1 · Figure 125 · LBA Format Data Structure, NVM Command Set Specific · 文件頁 94 · PDF 94 回情境索引 練習 05 128 KiB 資料為什麼可能超過 MDTS？主機準備一次傳輸 32 個 4 KiB logical blocks。請判斷 interleaved metadata 會不會讓這筆命令超限。
模擬回傳與已知條件
CAP.MPSMIN=0；CC.MPS=1；Identify Controller 的 MDTS=5、CTRATT.MEM=0。
使用中 LBAF：LBADS=12、MS=16；metadata 與資料交錯，這筆傳輸包含全部 16 metadata bytes／LBA。
沿著欄位一步步理解
查詢次序： 讀取 CAP.MPSMIN → Identify CNS=01h 的 MDTS／CTRATT.MEM → CNS=00h 的使用中格式；再檢查命令本身的限制。
推導 1 MDTS 以最小記憶體頁大小為基準，並非目前 CC.MPS。此例上限是 2^5 × 2^(12+0)=131072 bytes，即 128 KiB；不能因主機選了 8 KiB 頁，就把上限放大為 256 KiB。
推導 2 MEM=0 時，MDTS 計算包括交錯的 metadata。32 × (4096+16)=131584 bytes，已超出 131072；在本例條件下，31 個完整 blocks 才能放進此上限。
推導 3 若 MEM=1，這個 MDTS 比較只算資料，32 blocks 可通過這項檢查，但仍要滿足其他命令與 buffer 條件。MDTS=0 也只表示這個欄位未設最大值，不能推成每種命令都能接受任意長度。
完整原文定位 Base 2.4 · §3.1.4.1 · Figure 36 · Offset 0h: CAP – Controller Capabilities · 文件頁 55–58 · PDF 81–84 Base 2.4 · §5.2.14.2.1 · Figure 338 · Identify – Identify Controller Data Structure, I/O Command Set Independent · 文件頁 342, 345 · PDF 368, 371 NVM Command Set 1.3 · §4.1.5.1 · Figure 123 · Identify – Identify Namespace Data Structure, NVM Command Set · 文件頁 86–87 · PDF 86–87 NVM Command Set 1.3 · §4.1.5.1 · Figure 125 · LBA Format Data Structure, NVM Command Set Specific · 文件頁 94 · PDF 94 回情境索引 練習 06 Dataset Management 的限制是 0，代表不支援嗎？兩個 controller 的 DMRL 都是 0。請判斷能否只靠這個值關閉 Dataset Management 功能。
模擬回傳與已知條件
A：ONCS.NVMDSMSV=1；DMRL=0、DMRSL=0、DMSL=0。
B：ONCS.NVMDSMSV=0；DMRL=0、DMRSL=0、DMSL=0。
沿著欄位一步步理解
查詢次序： Identify CNS=01h 讀 ONCS；CNS=06h、CSI=00h 讀 NVM 專屬 controller 資料，再一起解 DMRL／DMRSL／DMSL。
CSI Command Set Identifier，命令集識別碼 推導 1 A 的 NVMDSMSV=1 已表示支援此命令；三個 0 表示這些欄位沒有報出相應的處理限制。不能把 DMRL=0 解成「允許 0 個 range」。
推導 2 B 使用另一種支援判斷：在 NVMDSMSV=0 的情況，必須連同這些 limit 的非零條件判讀。此組全 0 不提供 Dataset Management 支援，不能照搬 A 的結論。
推導 3 即使 A 支援，仍須遵守命令格式、namespace 範圍與每個 range 的定義。這題要練的是先讀能力版本，再解數值；0 沒有跨所有欄位通用的意思。
完整原文定位 Base 2.4 · §5.2.14.2.1 · Figure 338 · Identify – Identify Controller Data Structure, I/O Command Set Independent · 文件頁 372 · PDF 398 NVM Command Set 1.3 · §4.1.5.4 · Figure 129 · I/O Command Set Specific Identify Controller Data Structure for the NVM Command Set · 文件頁 103–106 · PDF 103–106 NVM Command Set 1.3 · §3.3.3.1 · 文件頁 45–47 · PDF 45–47 回情境索引 練習 07 有 LID 編號，就一定能讀那張 log 嗎？軟體認得某個 LID，但裝置可能不支援。應查哪一種資料，才不會把「軟體有名稱」當成「controller 有功能」？
模擬回傳與已知條件
Supported Log Pages 的目標項目 LSUPP=0；另一个項目 LSUPP=1。
本題先假設可成功讀取 Supported Log Pages；各目標 log 的 namespace、CSI 與 LSP 要求仍須另外確認。
沿著欄位一步步理解
查詢次序： Get Log Page，LID=00h；找到以目標 LID 編排的 supported-and-effects 項目，再讀該 log 的定義。
推導 1 LSUPP 是這個 controller 對該 log 的支援回報。0 的項目不能因軟體已有解碼器就視為受支援；1 的項目則通過支援檢查。
推導 2 支援並不表示 log 裡一定已有事件或量測結果。空紀錄、尚未產生的 Telemetry、以及不支援的 log 是不同狀態，報告應分開顯示。
推導 3 後續要依各 log 的 NSID、CSI、LSP、LSI、長度及 offset 規則送命令。LSUPP=1 不能讓錯誤的讀取參數自動變合法，也不能替代內容格式或版本檢查。
CSI Command Set Identifier，命令集識別碼 完整原文定位 Base 2.4 · §5.2.13.1.1 · Figure 211 · LID Supported and Effects Data Structure · 文件頁 217–218 · PDF 243–244 Base 2.4 · §5.2.13 · Figure 204 · Get Log Page – Command Dword 10 · 文件頁 213 · PDF 239 Base 2.4 · §5.2.13 · Figure 205 · Get Log Page – Command Dword 11 · 文件頁 214 · PDF 240 Base 2.4 · §5.2.13 · Figure 208 · Get Log Page – Command Dword 14 · 文件頁 214–215 · PDF 240–241 回情境索引 本冊圖表
Base 2.4 Figure 333 · Identify CDW10：選資料結構，不是選欄位 Base 2.4 Figure 336 · CNS 總表：查結構及有效參數 Base 2.4 Figure 338 · Identify Controller：能力與限制的主要入口 Base 2.4 Figure 342 · Namespace 識別描述子：不要把 NSID 當永久身分 Base 2.4 Figure 346 · Namespace 共通狀態：可用、受保護與儲存歸屬 NVM Command Set 1.3 Figure 123 · NVM Namespace：容量、格式、原子性與建議粒度 NVM Command Set 1.3 Figure 125 · LBAF：資料大小、metadata 大小與相對效能 NVM Command Set 1.3 Figure 127 · NVM 專屬 Namespace：延伸 PI 與格式能力 NVM Command Set 1.3 Figure 128 · ELBAF：Guard 格式與 Storage Tag 位數 NVM Command Set 1.3 Figure 129 · NVM 專屬 Controller：命令大小限制及其有效條件
01 Identify CDW10：選資料結構，不是選欄位Base 2.4 · Figure 333 · Identify – Command Dword 10
§5.2.14 · 文件頁 337 · PDF 363
01.1 · 用途 當 Identify 資料被解成不合理的容量或能力時，先回查命令選了哪種結構。不同 CNS 可能回傳同樣大小的 buffer，但各 byte 意義不同。
01.2 · 欄位與關係 CNS bits7:0 選回傳結構；CNTID bits31:16 只用於部分操作；bits15:8 保留。不使用 CNTID 的操作，主機應依規定清 0，不能把它當任意 controller selector。
01.3 · 判讀與例子 CNS=01h 讀處理此命令的 controller 資訊；CNS=00h 讀 NVM namespace 資訊。若用 01h 的 byte offset 去解析 00h，即使 buffer 長度正確，結論仍可能完全錯誤。
搜尋詞：Identify · CNS · CNTID · CNS 01h · CNS 00h
回本冊圖表索引
02 CNS 總表：查結構及有效參數Base 2.4 · Figure 336 · Identify – CNS Values
§5.2.14 · 文件頁 338–339 · PDF 364–365
02.1 · 用途 不知道應送哪個 Identify 操作時，從這張表按查詢對象選 CNS。每列同時列出 NSID、CNTID、CSI 是否使用，不能只抄 CNS 數字。
02.2 · 欄位與關係 常用 01h 為 controller、02h 為 active NSID list、03h 為 namespace 識別描述子；05h／06h 是 command-set-specific namespace／controller，08h 是 command-set-independent namespace。10h 查 allocated NSID list；16h 粒度、17h UUID list 等列也可由此找到來源。
02.3 · 判讀與例子 active list 與 allocated list 可能不同：已建立但未附加的 namespace，不一定在此 controller 的 active list。查不到時先確認選了哪份清單，而不是直接判定 namespace 不存在。
搜尋詞：CNS · NSID · CNTID · CSI · Identify list
回本冊圖表索引
03 Identify Controller：能力與限制的主要入口Base 2.4 · Figure 338 · Identify – Identify Controller Data Structure, I/O Command Set Independent
§5.2.14.2.1 · 文件頁 340–382 · PDF 366–408
03.1 · 用途 這張跨 43 頁的大表是 controller 能力、限制及識別資訊的主要來源。速查時先決定要確認哪一類問題，再用下方欄位頁碼前往；不要從第一頁一路掃到最後。
03.2 · 欄位與關係 傳輸大小查 MDTS，Admin 命令支援查 OACS，I/O 能力查 ONCS，log 支援與長度查 LPA／ELPE，韌體查 FRMW，清除查 SANICAP。queue entry 大小查 SQES／CQES，資料指標查 SGLS；NPSS 與 Power State Descriptors 則一起解讀電源狀態。
03.3 · 判讀與例子 MDTS 非 0 時，以 CAP.MPSMIN 定義的最小頁大小乘 2^MDTS；例如最小頁 4 KiB、MDTS=5 得到 128 KiB。MDTS=0 表示此欄不限制，不代表其他命令或 namespace 限制都消失。欄位的 O／M／R、controller 類型及腳註也屬有效條件。
大表內的欄位位置
欄位 查詢內容 PDF 頁 MDTS 傳輸大小上限 368 OACS Admin 命令支援 378–380 FRMW 韌體槽位與更新能力 380–381 LPA Log page 能力 381–382 ELPE / NPSS 錯誤項目上限／電源狀態數 382 SANICAP Sanitize 能力 387–388 SQES / CQES 佇列項目大小 396 ONCS I/O 命令與功能支援 397–399 VWC / AWUN / AWUPF 快取與原子性欄位 400 SGLS SGL 類型與對齊 403–404
SGL Scatter Gather List，描述分散資料區段的清單 搜尋詞：Identify Controller · MDTS · OACS · ONCS · LPA · ELPE · FRMW · SANICAP · SQES · CQES · SGLS · NPSS
回本冊圖表索引
04 Namespace 識別描述子：不要把 NSID 當永久身分Base 2.4 · Figure 342 · Identify – Namespace Identification Descriptor
§5.2.14.2.3 · 文件頁 388 · PDF 414
04.1 · 用途 要辨認兩次查詢或不同 controller 看到的 namespace 是否為同一物件，查這張識別描述子表。命令中的 NSID 是存取用的識別值，不能代替所有長期識別資訊。
04.2 · 欄位與關係 NIDT byte0 選類型，NIDL byte1 給 NID 長度，bytes3:2 保留，NID 從 byte4 開始。類型 1／2／3／4 分別是 8-byte EUI64、16-byte NGUID、16-byte UUID、1-byte CSI。每筆總長 NIDL+4；NIDL=0 表示清單結束。
04.3 · 判讀與例子 NIDL=16 的一筆佔 20bytes，下一筆從原起點+20 開始，不是+16。CSI 描述命令集，不能因為也放在 NID 位置就當成 globally unique identifier。
搜尋詞：NIDT · NIDL · NID · EUI64 · NGUID · UUID · CSI
回本冊圖表索引
05 Namespace 共通狀態：可用、受保護與儲存歸屬Base 2.4 · Figure 346 · Identify – I/O Command Set Independent Identify Namespace Data Structure
§5.2.14.2.8 · 文件頁 391–394 · PDF 417–420
05.1 · 用途 查 namespace 是否 ready、是否受寫入保護、屬於哪個資源群組時，使用這份與 I/O command set 無關的結構。它與 NVM CNS00h 的 byte 配置不同。
05.2 · 欄位與關係 常查 NSFEAT byte0、NMIC byte1、RESCAP byte2、FPI byte3；ANAGRPID 在 bytes7:4，NSATTR 在 byte8，後面還有 NVMSETID、ENDGID 與 NSTAT。FPI 表示剩餘 Format 百分比，NSATTR.CWP 表示目前受寫入保護，NSTAT.NRDY 表示 namespace 是否 ready。
05.3 · 判讀與例子 controller 的 CSTS.RDY=1 而 namespace 的 NRDY=0，可以是 media-independent ready 流程中的不同層級狀態，不應立刻視為互相矛盾。ENDGID 則用來接到對應 Endurance Group 的健康 log。
搜尋詞：CNS 08h · NSTAT · NRDY · NSATTR · FPI · ENDGID · NVMSETID · ANAGRPID
回本冊圖表索引
06 NVM Namespace：容量、格式、原子性與建議粒度NVM Command Set 1.3 · Figure 123 · Identify – Identify Namespace Data Structure, NVM Command Set
§4.1.5.1 · 文件頁 85–93 · PDF 85–93
06.1 · 用途 容量數字、LBA 格式或對齊行為有疑問時，這張表是 NVM namespace 的主要入口。先分清目前格式、支援格式清單與建議效能參數。
06.2 · 欄位與關係 NSZE bytes7:0 是可定址 blocks 總數，NCAP15:8 是最多可配置量，NUSE23:16 是目前配置量。FLBAS byte26 選格式，DPS byte29 選 PI 設定，DLFEAT byte33 描述 deallocate 後行為；後續 NAWUN／NAWUPF 與 boundary 欄位補原子性，LBAF 清單提供各格式大小。
PI Protection Information，資料保護資訊 06.3 · 判讀與例子 NSZE=1000 表示 LBA0～999；若所選 LBADS=12，資料容量是 1000×4096=4,096,000 bytes。FLBAS=12h 不是 18-byte 格式，而是 format index2 加 metadata 傳輸設定；大小要再讀該 LBAF。
大表內的欄位位置
欄位 查詢內容 PDF 頁 NSZE / NCAP / NUSE / NSFEAT 容量與功能條件 85–86 FLBAS / MC / DPC / DPS 格式與保護設定 86–87 DLFEAT / NAWUN / NAWUPF Deallocate 行為與原子單位 88–89 NABSN / NABO / NABSPF 原子性邊界 89 NPWG / NPWA / NPDG / NPDA 效能建議粒度與對齊 90 LBAF 格式清單的位置與數量 93
搜尋詞：CNS 00h · NSZE · NCAP · NUSE · FLBAS · DPS · DLFEAT · LBAF · NAWUN · NABSN
回本冊圖表索引
07 LBAF：資料大小、metadata 大小與相對效能NVM Command Set 1.3 · Figure 125 · LBA Format Data Structure, NVM Command Set Specific
§4.1.5.1 · 文件頁 94 · PDF 94
07.1 · 用途 FLBAS 已選出 format index 後，到這張表解該格式的 4-byte 描述子。它回答每個 logical block 的資料和 metadata 各有多大。
07.2 · 欄位與關係 MS bits15:0 直接以 bytes 表示 metadata；LBADS bits23:16 是資料 bytes 的 2 次方指數，0 表示該格式目前不可用；RP bits25:24 是指定測試情境下的相對效能等級，不是 IOPS 數值。
07.3 · 判讀與例子 LBADS=12、MS=8 代表 4096-byte 資料加 8-byte metadata。若採 extended LBA，傳輸排列每 block 共 4104 bytes；LBADS 不包含這 8bytes，也不能把 RP=0 當作所有工作負載一定最快。
搜尋詞：LBAF · LBADS · MS · RP
回本冊圖表索引
08 NVM 專屬 Namespace：延伸 PI 與格式能力
PI Protection Information，資料保護資訊 NVM Command Set 1.3 · Figure 127 · NVM Command Set I/O Command Set Specific Identify Namespace Data Structure
§4.1.5.3 · 文件頁 97–101 · PDF 97–101
08.1 · 用途 需要解 32／64-bit Guard、Storage Tag 或延伸格式時，CNS00h 不夠，還要查這份 CNS05h、CSI00h 資料。它補充格式能力，不取代目前 namespace 的 FLBAS／DPS。
08.2 · 欄位與關係 LBSTM 提供 Storage Tag mask，PIC 列保護格式能力；ELBAF 陣列對應各 format index，描述 Guard 格式與 Storage Tag 寬度。相關 mask 有效性還受保護資訊是否啟用，以及 PIC 和 masking-level 能力限制。
08.3 · 判讀與例子 同一個 format index 應在 LBAF 與 ELBAF 配對：前者提供資料／metadata bytes，後者提供 PI 內部格式。只看到 metadata 有 16bytes，無法直接判定 Guard 一定是 64bits。
搜尋詞：CNS 05h · CSI 00h · LBSTM · PIC · ELBAF · Storage Tag
回本冊圖表索引
09 ELBAF：Guard 格式與 Storage Tag 位數NVM Command Set 1.3 · Figure 128 · Extended LBA Format Data Structure, NVM Command Set Specific
§4.1.5.3 · 文件頁 101–102 · PDF 101–102
09.1 · 用途 查 PI 資料為何解析錯位時，用這張表確定 Guard 格式以及 Storage／Reference 區域如何切割。STS 在這裡是 Storage Tag Size，不能當成 status。
09.2 · 欄位與關係 STS bits6:0 指定 Storage Tag 位數；PIF bits8:7 選 16／32／64-bit Guard 或 qualified 格式；只有 PIF=11b 且相關能力成立時，才使用 QPIF bits12:9。PI 未啟用時，不能依這些欄位推論實際傳輸含有 PI。
09.3 · 判讀與例子 PIF=10b、STS=16 表示 64-bit Guard 格式，其中 48-bit Storage／Reference 區的高 16bits 給 Storage Tag，剩 32bits 給 Reference Tag。16、32、64-bit Guard 允許的 STS 範圍不同，不能任意套同一個遮罩。
搜尋詞：ELBAF · PIF · QPIF · STS · QPIFS
回本冊圖表索引
10 NVM 專屬 Controller：命令大小限制及其有效條件NVM Command Set 1.3 · Figure 129 · I/O Command Set Specific Identify Controller Data Structure for the NVM Command Set
§4.1.5.4 · 文件頁 103–106 · PDF 103–106
10.1 · 用途 Verify、Write Zeroes 或 Dataset Management 因大小被拒絕時，查這份 CNS06h、CSI00h 結構。Base 的 MDTS 不是每個命令唯一的大小限制。
10.2 · 欄位與關係 VSL／WZSL／WUSL 是以最小記憶體頁為基礎的指數式大小；DMRL 是 range 數，DMRSL 是單一 range 的 blocks，DMSL 是合計 blocks。ONCS 內各命令的 support-variant bits 會改變欄位是強制上限還是建議值，也會改變 0 的含義。
10.3 · 判讀與例子 例如 DMRL=0 且 NVMDSMSV=1 表示未回報建議 range 數上限；NVMDSMSV=0 時，DMRL=0 則表示不支援 Dataset Management。不能把所有 0 都翻成「無限制」。
大表內的欄位位置
欄位 查詢內容 PDF 頁 VSL / WZSL Verify／Write Zeroes 大小 103 WUSL / DMRL / DMRSL Write Uncorrectable 與 DSM range 限制 104 DMSL / KPIOCAP / WZDSL 總 blocks、金鑰能力、deallocate 大小 105 AOCS / VER / RLA Admin 能力、版本與速率限制能力 106
搜尋詞：CNS 06h · CSI 00h · VSL · WZSL · WUSL · DMRL · DMRSL · DMSL · NVMDSMSV
回本冊圖表索引