NVM Express Base 2.4NVM Command Set 1.3NVMe over PCIe Transport 1.4

反覆查詢 · 欄位判讀 · 原文定位

NVMe 圖表判讀與情境練習 03 · Identify、Namespace 與資料格式

CNS 決定回傳哪一種 Identify 結構；controller 能力、namespace 格式和選定格式的大小要分開查，再組合成可用設定。

CNS: Controller or Namespace Structure，選擇Identify回傳結構

先跟著一個情境讀規格

以下回傳資料均為教學假設。先看需求與已知條件，再沿閱讀路線找到相關欄位，接著一起判讀結果。完整解說直接顯示，來源細節可另外展開。

練習 01最多還能建立幾個 namespace？

管理程式把 NN 當成可建立的 namespace 數量。你要怎麼修正它，並回答「現在還能建立幾個」？

模擬回傳與已知條件

OACS.NMS=1；NN=1000；MNAN=16；MAXCNA=8。
完整 Allocated Namespace ID list 有 10 筆；此 controller 的 Active list 有 6 筆。剩餘容量與建立參數尚未查詢。

這個情境要連起哪些規格圖表？

下面是閱讀規格的順序；實際操作的先後與等待條件，會在情境解說中另外交代。

先選對 Identify 結構
由 CNS 總表選擇 controller、已配置清單與活動清單。先確定回覆的對象，再比較數量。
Base 2.4 · Figure 336
分別讀數量與附接限制
在 Identify Controller 找 NN、MNAN 與 MAXCNA 的定義及有效條件，再搭配兩份清單的筆數。
Base 2.4 · Figure 338
接著確認建立所需資源
Namespace Management 的操作與主機指定欄位說明建立時還要提供什麼。數量名額只是其中一項前提。
Base 2.4 · Figure 446 NVM Command Set 1.3 · Figure 134

沿著欄位一步步理解

查詢次序：Identify CNS=01h → CNS=10h 完整已配置清單 → CNS=02h 此 controller 的活動清單；必要時再查容量與 Namespace Management 參數。

推導 1NN 是有效 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

回情境索引

接著看其他情境

練習 02namespace 存在，為什麼這個 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。

推導 127 在有效範圍，而且出現在 Allocated list，表示該 namespace 已存在。它不在此 controller 的 Active list，只能得出它未附接到此 controller；不能說它不存在，更不能說媒體上的資料已遺失。

推導 2CNS=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 解析識別描述子，保留識別值。

推導 1NSID 是命令選擇 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。

推導 1LBADS=12 表示每個 LBA 的資料大小是 2^12=4096 bytes。NSZE=8192 給出 32 MiB 的可定址資料範圍，合法 LBA 是 0 到 8191，不是到 8192。

LBA: Logical Block Address，邏輯區塊位址

推導 2NCAP=4096 是最多可配置的 logical blocks，換算為 16 MiB；NUSE=1024 是目前已配置的 logical blocks，換算為 4 MiB。它們從不同角度描述同一 namespace，並不是三塊可相加的獨立空間。

推導 3NUSE 也不是檔案系統的已用容量。檔案刪除、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

回情境索引

練習 05128 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 的使用中格式；再檢查命令本身的限制。

推導 1MDTS 以最小記憶體頁大小為基準，並非目前 CC.MPS。此例上限是 2^5 × 2^(12+0)=131072 bytes，即 128 KiB；不能因主機選了 8 KiB 頁，就把上限放大為 256 KiB。

推導 2MEM=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

回情境索引

練習 06Dataset 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，命令集識別碼

推導 1A 的 NVMDSMSV=1 已表示支援此命令；三個 0 表示這些欄位沒有報出相應的處理限制。不能把 DMRL=0 解成「允許 0 個 range」。

推導 2B 使用另一種支援判斷：在 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 的定義。

推導 1LSUPP 是這個 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

回情境索引

01Identify 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

回本冊圖表索引

02CNS 總表：查結構及有效參數

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

回本冊圖表索引

03Identify 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

回本冊圖表索引

04Namespace 識別描述子：不要把 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

回本冊圖表索引

05Namespace 共通狀態：可用、受保護與儲存歸屬

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

回本冊圖表索引

06NVM 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

回本冊圖表索引

07LBAF：資料大小、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

回本冊圖表索引

08NVM 專屬 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

回本冊圖表索引

09ELBAF：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

回本冊圖表索引

10NVM 專屬 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

回本冊圖表索引

NVMe 圖表判讀與情境練習 03 · Identify、Namespace 與資料格式

NVMe 圖表判讀與情境練習 03 · Identify、Namespace 與資料格式

先跟著一個情境讀規格

練習 01最多還能建立幾個 namespace？

模擬回傳與已知條件

這個情境要連起哪些規格圖表？

接著看其他情境

練習 02namespace 存在，為什麼這個 controller 看不到？

模擬回傳與已知條件

練習 03重開機後 NSID 改了，還是同一份資料嗎？

模擬回傳與已知條件

練習 04容量是位址範圍、可配置量，還是已使用量？

模擬回傳與已知條件

練習 05128 KiB 資料為什麼可能超過 MDTS？

模擬回傳與已知條件

練習 06Dataset Management 的限制是 0，代表不支援嗎？

模擬回傳與已知條件

練習 07有 LID 編號，就一定能讀那張 log 嗎？

模擬回傳與已知條件

01Identify CDW10：選資料結構，不是選欄位

02CNS 總表：查結構及有效參數

03Identify Controller：能力與限制的主要入口

大表內的欄位位置

04Namespace 識別描述子：不要把 NSID 當永久身分

05Namespace 共通狀態：可用、受保護與儲存歸屬

06NVM Namespace：容量、格式、原子性與建議粒度

大表內的欄位位置

07LBAF：資料大小、metadata 大小與相對效能

08NVM 專屬 Namespace：延伸 PI 與格式能力

09ELBAF：Guard 格式與 Storage Tag 位數

10NVM 專屬 Controller：命令大小限制及其有效條件

大表內的欄位位置

Jia-Chang

Recent posts

Comments