NVMe 自問自答題庫:Domain、Reclaim Group 與 Media Unit

NVMe · Q1–328

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

Q268–Q275

Domain、Reclaim Group 與 Media Unit

管理歸屬與 FDP 放置關係要用不同視角閱讀。本冊先辨認各種 ID 的範圍,再追蹤一筆 Write 如何選到 RU,最後解讀媒體資訊的限制。

FDP
Flexible Data Placement,彈性資料放置

每個問題都接著完整解說,依內容帶讀欄位、比較機制或追蹤流程。先看本冊總覽,再沿問題閱讀;必要條件與正常路徑直接顯示。所有數字案例均為教學假設;Status 以 SCT/SC 表示,代碼後的 h 代表十六進位。

SCT
Status Code Type,完成狀態代碼類型

從 Write 的 PID 走到目前 RU

PID 裡的 PH 不是 RUH ID;必須先經過 namespace 的對照表。

步驟假設值選到什麼
解 PIDRGID=1、PH=0指定 RG1 及 namespace 的 PH0
查對照NS1.PH0→RUH2選 RUH2
查目前參照RUH2 在 RG1 參照 RU 乙這次 Write 使用的 RU
RU 用滿後controller 更換目前 RUPH 可不變,實際 RU 改變

舉例看懂:若另一 namespace 的 PH0 對 RUH3,即使兩筆 Write 的 PID 數字相同,也可能使用不同 RUH。比較前必須保留 NSID 與配置。

NSID
Namespace Identifier,邏輯儲存空間識別碼

來源:Base 2.4 §3.2.4, 8.1.12 · Base 2.4 §5.2.13.1.29–5.2.13.1.32, 5.2.30.1.21–5.2.30.1.22, 7.3–7.4 · NVM Command Set 1.3 §3.2, 4.1.4.6–4.1.4.7 · Base 2.4 §5.2.13.1.16

需要時回顧本篇名詞
Controller / namespace
controller 接收命令並管理存取;namespace 是命令可指定的一份邏輯儲存空間。NVM subsystem 則包含 controller 與非揮發儲存資源,同一 subsystem 可以有多個 controller。
SQ / CQ / SQE / CQE
Submission Queue(SQ)是提交佇列,Completion Queue(CQ)是完成佇列;SQE 與 CQE 分別是其中的一筆命令及完成項目。QID 識別 queue,CID 區分同一 SQ 中尚未完成的命令,NSID 則識別 namespace。
Register / Identify / Feature / Log
Register 提供可存取的控制或狀態資訊;Identify 查詢物件的能力與屬性;Feature 用來讀取或變更工作設定;Log Page 回報特定種類的狀態或紀錄。FID、LID、CNS、CSI 則分別用來選擇 Feature、Log Page、Identify 資料結構及命令集。
index / offset / zero-based
index 指出清單中的第幾筆,通常從 0 起算;offset 表示與起點相隔多遠,解讀時必須確認單位。若數量欄位採 zero-based 編碼,實際數量等於欄位值加 1;但不是所有欄位看到 0 都要加 1。Dword 是 4 bytes,1 byte 是 8 bits。
Scope / reset / retention
scope 表示操作影響哪些物件;retention 表示狀態是否保留。清除 CC.EN 所觸發的 Controller Reset,是 Controller Level Reset(CLR)的一種。同屬 CLR 的不同觸發方式,仍可能採用不同的 Register 保留規則。

本冊題目

  1. Q268 · Domain、Set、Group、Media Unit 與 Namespace 是單一層級嗎?
  2. Q269 · 如何取得 Domain 與資源歸屬?
  3. Q270 · Reclaim Group、Reclaim Unit 與 RU Handle 各代表什麼?
  4. Q271 · Namespace 如何透過 Placement Handle 選擇 RU?
  5. Q272 · Media Unit Status Log 提供哪些資訊,如何走訪描述資料?
  6. Q273 · 能從 Media Unit Status 直接判斷 Namespace 不可用嗎?
  7. Q274 · 媒體狀態變化會產生哪些通知與紀錄?
  8. Q275 · 如何辨識管理實體的 Scope,避免混用 ID?

Q268 Domain、Set、Group、Media Unit 與 Namespace 是單一層級嗎?

跟著解說理解

這些名稱描述不同觀點:Domain 是管理與通訊邊界,Group 管耐用度,Set 組織容量,Namespace 提供邏輯位址,FDP 則決定資料放置。

FDP
Flexible Data Placement,彈性資料放置

1. 差別在哪裡

支援 Set 時,namespace 位於一個 Set,Set 位於一個 Endurance Group,Group 位於一個 Domain;Reclaim Group 不是再插入這條鏈的一層 namespace 容器。

Media Unit 是規範提供的媒體資訊單位;Reclaim Unit 是 FDP 的回收單位,兩者不能直接畫上等號。

2. 如何選擇與確認

讀 CTRATT、各 Identify List、Namespace 歸屬及 FDP Configurations,不從名詞相似推測支援。

先畫管理歸屬,再另外畫 Placement Handle 如何選到 RUH 與 RU。兩張圖各自回答「屬於誰」和「放在哪裡」。

可以說明一個 namespace 的歸屬,以及它的資料如何透過 FDP 放到所選資源,而不虛構一對一關係。

3. 比較時要保留的條件

Media Unit 不保證等於一顆 die;Channel 與 Media Unit 的關係也不能一律當成單一路徑。

對照各 ID 的定義、有效範圍及查詢時點;相同數值出現在不同 ID 欄不表示同一物件。

來源:Base 2.4 §3.2.2–3.2.3, 3.8 · Base 2.4 §5.2.13.1.16 · Base 2.4 §3.2.4, 8.1.12 · Base 2.4 §5.2.13.1.29–5.2.13.1.32, 5.2.30.1.21–5.2.30.1.22, 7.3–7.4 · NVM Command Set 1.3 §3.2, 4.1.4.6–4.1.4.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 §5.2.14.2.2–5.2.14.2.19, 5.2.14.3.1–5.2.14.3.2 · Base 2.4 §2.4.2, 8.1.1 (PCIe namespace access) · 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)

回本冊題目

Q269 如何取得 Domain 與資源歸屬?

跟著解說理解

在多 Domain 裝置中,先確定查詢視角,才知道容量與資源清單涵蓋哪個範圍。

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

Domain 可以沒有 controller,也可以沒有 Endurance Group,不能只靠目前看得到的 controller 數量推算所有 Domain。

查 CTRATT.MDS、Identify Controller 的 Domain 資訊,以及 Domain、Endurance Group、Set 清單。

Identify Namespace 的 ENDGID、NVMSETID 描述歸屬;Media Unit Status 的 DID、ENDGID、NVMSETID 則提供媒體端關係。

2. 查詢順序與回覆判讀

先取得有效 DID,再列資源與 namespace,將每筆紀錄的 controller 和 DID 一起保存。

同一張對照表能回答某 namespace 使用哪個 Group,以及查到的容量屬於哪個 Domain。

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

LID10h 的 LSI.DID=0 指目前 controller 所在 Domain;非法非零 DID 必須回 Invalid Field,不能悄悄查另一個 Domain。

單 Domain 與多 Domain 的零值定義不同,需搭配 MDS 判讀;不要把缺少跨 Domain 資訊當成該資源不存在。

先看查詢是送到哪個 controller,以及 selector 是否明確指定 Domain。

來源:Base 2.4 §3.2.2–3.2.3, 3.8 · Base 2.4 §5.2.13.1.16 · Base 2.4 §3.2.4, 8.1.12 · Base 2.4 §5.2.13.1.29–5.2.13.1.32, 5.2.30.1.21–5.2.30.1.22, 7.3–7.4 · NVM Command Set 1.3 §3.2, 4.1.4.6–4.1.4.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 §5.2.14.2.2–5.2.14.2.19, 5.2.14.3.1–5.2.14.3.2 · Base 2.4 §2.4.2, 8.1.1 (PCIe namespace access) · 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)

回本冊題目

Q270 Reclaim Group、Reclaim Unit 與 RU Handle 各代表什麼?

跟著解說理解

FDP 讓 Host 表達資料放置意圖,controller 仍負責實際回收及更換使用中的 RU。

1. 差別在哪裡

FDP 配置以 Endurance Group 為範圍;RG 與 RUH 的 ID 只在該配置中有意義。

RG 收納可回收的 RUs;一個 RUH 在每個 RG 各參照一個 RU。同一 RU 同時最多由一個 RUH 參照。

2. 如何選擇與確認

讀 LID20h 的 NRG、NRUH 與 RUH descriptors,再查 FID1Dh 是否啟用及所選配置。

Host 先選 RG 與 Placement Handle,再由 handle 對到 RUH。當目前 RU 用滿,controller 在同一 RG 換成另一個空 RU。

教學例:RUH2 可同時參照 RG0 的 RU 甲與 RG1 的 RU 乙;只給 RUH2 還不能唯一指定這兩者之一。

3. 比較時要保留的條件

Initially Isolated 與 Persistently Isolated 對回收時混放資料的要求不同,不能只靠 RUH 編號推論永久隔離。

將所選配置、RG、RUH 類型與目前狀態一起比對;RUH ID 固定不代表其參照的 RU 永遠不變。

來源:Base 2.4 §3.2.2–3.2.3, 3.8 · Base 2.4 §5.2.13.1.16 · Base 2.4 §3.2.4, 8.1.12 · Base 2.4 §5.2.13.1.29–5.2.13.1.32, 5.2.30.1.21–5.2.30.1.22, 7.3–7.4 · NVM Command Set 1.3 §3.2, 4.1.4.6–4.1.4.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 §5.2.14.2.2–5.2.14.2.19, 5.2.14.3.1–5.2.14.3.2 · Base 2.4 §2.4.2, 8.1.1 (PCIe namespace access) · 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)

回本冊題目

Q271 Namespace 如何透過 Placement Handle 選擇 RU?

跟著解說理解

Namespace 使用自己的 Placement Handle 清單,將 Write 中的放置意圖轉成 Group 內的 RUH。

1. 操作前先準備什麼

同一 PH 數值在不同 namespace 可以對到不同 RUH;不同 namespaces 也可能共用 RUH,須符合配置限制。

讀 namespace 的 handle 清單、FDP 配置與 I/O Management Receive 的 RUH Status。

Write 的 DTYPE=02h 啟用 FDP 指示,DSPEC 的 PID 包含 RGID 與 PH;PID 裡不是直接填 RUH ID。

2. 先後順序與完成條件

先解 PID,再以 PH 查出 RUH,最後用 RGID 找到該 RUH 在所選 RG 目前參照的 RU。

例如 NS1 的 PH0 對 RUH2、PID 選 RG1,就使用 RUH2 在 RG1 的目前 RU;不是 RUH0。

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

Write 的 PID 非法時,controller 必須改選可存取的 RG/RUH,並依啟用設定記 Invalid PID 事件;RUH Update 的非法參數不能套用相同容錯。

未使用 FDP Directive 的 Write 走 PH0 與 controller 所選 RG;不能因此宣稱完全繞過 FDP 配置。

來源:Base 2.4 §3.2.2–3.2.3, 3.8 · Base 2.4 §5.2.13.1.16 · Base 2.4 §3.2.4, 8.1.12 · Base 2.4 §5.2.13.1.29–5.2.13.1.32, 5.2.30.1.21–5.2.30.1.22, 7.3–7.4 · NVM Command Set 1.3 §3.2, 4.1.4.6–4.1.4.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 §5.2.14.2.2–5.2.14.2.19, 5.2.14.3.1–5.2.14.3.2 · Base 2.4 §2.4.2, 8.1.1 (PCIe namespace access) · 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)

回本冊題目

Q272 Media Unit Status Log 提供哪些資訊,如何走訪描述資料?

跟著解說理解

這份 Log 用來查看 Domain 中媒體單位的歸屬、容量調整與耗損資訊,不是逐筆 I/O 的完成紀錄。

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

LID10h 以 LSI.DID 選 Domain;Media Unit ID 與 Channel ID 的唯一性範圍是 Domain。

查 Supported Log Pages 與 Domain 支援,再取得 Header 的 NMU、CCHANS、SELC。

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

描述資料包含 MUID、DID、ENDGID、NVMSETID、CAF、AVSP、PUSED、MUCS 與 CIO;CIO 指向 Channel 清單,MUCS 是清單筆數。

以 CIO 找清單起點,以 MUCS×2 bytes 讀 Channel IDs;有 Channel 清單時,描述資料長度由 CIO 加清單長度推算,不能固定每筆都是同樣大小。

Channel IDs 需按順序讀取;CCHANS=0 表示未回報共同 Channel 數,不能直接當作裝置沒有 Channel。

3. 判讀時要保留的條件

SELC=0 代表已清除容量配置時,Group、Set、CAF 與 Channel 數等欄須依其清零規則解讀,不能當作一般已配置狀態。

Media Unit 的 AVSP、PUSED 與 Endurance Group 健康值之間,規範沒有要求簡單平均關係。

來源:Base 2.4 §3.2.2–3.2.3, 3.8 · Base 2.4 §5.2.13.1.16 · Base 2.4 §3.2.4, 8.1.12 · Base 2.4 §5.2.13.1.29–5.2.13.1.32, 5.2.30.1.21–5.2.30.1.22, 7.3–7.4 · NVM Command Set 1.3 §3.2, 4.1.4.6–4.1.4.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 §5.2.14.2.2–5.2.14.2.19, 5.2.14.3.1–5.2.14.3.2 · Base 2.4 §2.4.2, 8.1.1 (PCIe namespace access) · 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)

回本冊題目

Q273 能從 Media Unit Status 直接判斷 Namespace 不可用嗎?

跟著解說理解

不能直接判斷。Media Unit Status Log(LID10h)沒有一個能直接換算成 Namespace Ready 的通用狀態;必須再查看 namespace 與存取路徑的證據。

1. 耗損數值不是 Ready 狀態

媒體耗損、namespace 存取狀態與某條 controller 路徑是否可用,是不同觀察範圍。

PUSED 估算耐用度消耗,AVSP 描述 spare;兩者都不是 Namespace Not Ready 的直接編碼。

PUSED 超過 100 不等於所有讀寫必須失敗;裝置仍可依其實際能力繼續服務。

2. 存取失敗時,應依什麼證據判斷

查 namespace 歸屬、controller Ready、適用 ANA 狀態及實際命令結果;Media Unit Log 只補充媒體資訊。

先確認 namespace 已附加且路徑允許存取,再觀察合法命令失敗原因,最後才查共享媒體是否能解釋影響範圍。

Namespace Not Ready、ANA Inaccessible 與媒體錯誤分屬不同原因,應按實際條件與對應 Status 判斷。

若多個 namespaces 同時受影響,檢查共用的 Group、Set 或 controller,仍不能只憑同時發生就證明因果。

來源:Base 2.4 §3.2.2–3.2.3, 3.8 · Base 2.4 §5.2.13.1.16 · Base 2.4 §3.2.4, 8.1.12 · Base 2.4 §5.2.13.1.29–5.2.13.1.32, 5.2.30.1.21–5.2.30.1.22, 7.3–7.4 · NVM Command Set 1.3 §3.2, 4.1.4.6–4.1.4.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 §5.2.14.2.2–5.2.14.2.19, 5.2.14.3.1–5.2.14.3.2 · Base 2.4 §2.4.2, 8.1.1 (PCIe namespace access) · 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)

回本冊題目

Q274 媒體狀態變化會產生哪些通知與紀錄?

跟著解說理解

規範沒有通用的「Media Unit 任一欄變更」AER。必須先辨識實際變化屬於健康警告、ANA、namespace 屬性還是 FDP 事件。

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

警告可能屬於 Endurance Group、subsystem,或僅屬於某 controller 的路徑;這些通知不能互相代替。

讀 AEC、FID18h、FDP Event 設定與對應支援位元。

SMART/Endurance Group Logs 提供警告,ANA Log 提供路徑狀態,FDP Events 記錄已啟用的放置事件。

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

先保存 AER 的 Type、Information、LID,再讀相符 Log;需要保留事件時使用 RAE=1。

LID
Log Page Identifier,紀錄頁識別碼

例如某 Group spare 低於門檻,應檢查 EGCW 與已啟用的 aggregate notice,而非期待一個 Media Unit Lost 事件。

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

沒有事件前,先排除未啟用、沒有掛 AER、已被別的讀取確認,或變化根本不符合事件條件。

PEL 只有在支援且符合指定事件時記錄;不能要求每次 PUSED 更新都新增事件。

先確定「哪個欄位如何改變」,再找規範定義的事件。

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

讀取 Log 本身不是新增一個事件的理由;不過,RAE=0 的成功讀取可能確認並清除對應事件。 完整條件見本冊說明

Get Log Page 回傳指定 Log 的資料。 完整條件見本冊說明

Get Log Page 不是 PEL 中逐筆記錄的讀取歷史。 完整條件見本冊說明

來源:Base 2.4 §3.2.2–3.2.3, 3.8 · Base 2.4 §5.2.13.1.16 · Base 2.4 §3.2.4, 8.1.12 · Base 2.4 §5.2.13.1.29–5.2.13.1.32, 5.2.30.1.21–5.2.30.1.22, 7.3–7.4 · NVM Command Set 1.3 §3.2, 4.1.4.6–4.1.4.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 §5.2.14.2.2–5.2.14.2.19, 5.2.14.3.1–5.2.14.3.2 · Base 2.4 §2.4.2, 8.1.1 (PCIe namespace access) · 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)

回本冊題目

Q275 如何辨識管理實體的 Scope,避免混用 ID?

跟著解說理解

相同數字可以同時是 NSID、DID、ENDGID 或 RGID;完整識別需要欄位種類與其所屬範圍。

NSID
Namespace Identifier,邏輯儲存空間識別碼

1. 機制與適用範圍

操作的命令入口、設定的範圍與資料的歸屬可能不同。

記錄 controller ID、Domain、Group、Namespace 與命令 selector;不適用的欄位明確留空,不填猜測的 0。

2. 用操作與結果理解

先查命令/Feature 的 scope,再用 Identify 和相關清單解析指定 ID。

逐步回答「送給誰、指定誰、誰會一起受影響」,再選擇跨 controller 的比對對象。

例如 FDP 的 FID1Dh 以 Group 為範圍;同 Group 的 namespaces 共用配置,但各自 PH 清單仍不同。

3. 容易誤判的地方

不存在 ID、未支援功能與無法取得跨 Domain 資訊,不能全部用同一種錯誤解釋。

同一物件的比較需保持 selector 與時間一致;若管理操作途中改變歸屬,先重新探索。

來源:Base 2.4 §3.2.2–3.2.3, 3.8 · Base 2.4 §5.2.13.1.16 · Base 2.4 §3.2.4, 8.1.12 · Base 2.4 §5.2.13.1.29–5.2.13.1.32, 5.2.30.1.21–5.2.30.1.22, 7.3–7.4 · NVM Command Set 1.3 §3.2, 4.1.4.6–4.1.4.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 §5.2.14.2.2–5.2.14.2.19, 5.2.14.3.1–5.2.14.3.2 · Base 2.4 §2.4.2, 8.1.1 (PCIe namespace access) · 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)

回本冊題目

共用規則:各題連到的完整解釋

這些規則在本冊只完整說明一次。返回剛才的題目可用瀏覽器「上一頁」;特定命令或 Feature 的明文例外優先。

本主題的共用條件 · 是否產生 Asynchronous Event?

讀取 Log 本身不是新增一個事件的理由;不過,RAE=0 的成功讀取可能確認並清除對應事件。RAE=1 保留事件,讀取失敗也必須保留。Immediate 與 One-Shot 事件另有清除方式,不能全部套用讀 Log 確認。

本主題的共用條件 · 是否更新 Error Information Log 或其他 Log?

Get Log Page 回傳指定 Log 的資料。某些清單會因讀取而清除已回報的變更,某些事件也受 RAE 影響;讀取前先保存需要比對的狀態。讀取成功本身不要求新增 Error Information,失敗時則依 CQE 與錯誤記錄規則判斷。

CQE
Completion Queue Entry,佇列中的完成項目

本主題的共用條件 · 是否記錄於 Persistent Event Log?

Get Log Page 不是 PEL 中逐筆記錄的讀取歷史。即使讀取的是 PEL,也不表示這次讀取會新增同類事件;只有另行發生且符合支援與記錄條件的事件,才依規則記錄。

原文定位與既有圖表判讀

Base 的文件頁碼等於 PDF 頁碼減 26;NVM 與 PCIe 兩份規格的文件頁碼則與 PDF 頁碼相同。以下依提供的 PDF 本文列出章節、頁碼及 Figure 編號。若同一頁包含其他主題,只引用本題需要的定義,不納入 Fabrics 或 PCIe Link、封包內容。

  • Base 2.4 · §2.4.2, 8.1.1 (PCIe namespace access)
    文件頁 37, 578–584 · PDF 63, 604–610 · Figure 675–678
  • Base 2.4 · §3.2.2–3.2.3, 3.8
    文件頁 80–84, 125–129 · PDF 106–110, 151–155 · Figure 67–69, 86–89
  • Base 2.4 · §3.2.4, 8.1.12
    文件頁 84–87, 648–652 · PDF 110–113, 674–678 · Figure 70–72, 730–732
  • Base 2.4 · §3.7.1–3.7.4
    文件頁 120–124 · PDF 146–150
  • Base 2.4 · §4.2.3
    文件頁 145–155 · PDF 171–181 · Figure 101–105
  • Base 2.4 · §5.2.2
    文件頁 183–190 · PDF 209–216 · Figure 150–156
  • Base 2.4 · §5.2.13.1.2
    文件頁 218–220 · PDF 244–246 · Figure 212
  • Base 2.4 · §5.2.13.1.14 (header, reset, hardware, Set Feature events)
    文件頁 244–256, 258, 262–264 · PDF 270–282, 284, 288–290 · Figure 232–244, 246, 252–253
  • Base 2.4 · §5.2.13.1.16
    文件頁 270–272 · PDF 296–298 · Figure 262–264
  • Base 2.4 · §5.2.13.1.29–5.2.13.1.32, 5.2.30.1.21–5.2.30.1.22, 7.3–7.4
    文件頁 293–301, 480–483, 568–571 · PDF 319–327, 506–509, 594–597 · Figure 293–303, 499–506, 650–657
  • Base 2.4 · §5.2.14.2.1
    文件頁 340–387 · PDF 366–413 · Figure 338–341
  • Base 2.4 · §5.2.14.2.2–5.2.14.2.19, 5.2.14.3.1–5.2.14.3.2
    文件頁 387–399, 402–404 · PDF 413–425, 428–430 · Figure 342–355, 360–362
  • NVM Command Set 1.3 · §3.2, 4.1.4.6–4.1.4.7
    文件頁 26, 79 · PDF 26, 79 · Figure 21, 116
  • NVM Command Set 1.3 · §4.1.5.1–4.1.5.4
    文件頁 84–107 · PDF 84–107 · Figure 123–130

需要看欄位圖時

以下連結可開啟對應的圖表教學,查閱欄位及判讀方式。每張圖保留固定的教學位置,方便之後反覆查詢。

使用的原始文件
  • NVM Express Base Specification · Revision 2.4 · 2026-07-31
    NVM-Express-Base-Specification-Revision-2.4-Ratified-2026.07.31.pdf
  • NVM Express NVM Command Set Specification · Revision 1.3 · 2026-07-31
    NVM-Express-NVM-Command-Set-Specification-Revision-1.3-Ratified-2026.07.31.pdf
  • NVM Express NVMe over PCIe Transport Specification · Revision 1.4 · 2026-07-31
    NVM-Express-NVMe-over-PCIe-Transport-Specification-Revision-1.4-Ratified-2026.07.31.pdf
Jia-Chang

Jia-Chang

Human

Comments

  Write a comment ...