觀察對象與健康狀態
01-01先分清 Group、Set、namespace 的歸屬，再讀警告與壽命估計；避免把一組的資訊當作整台裝置的結論。
- namespace
- 主機可用 NSID 指定的邏輯儲存空間。
NVMe · 規格與原理
NVMe Endurance Group：健康資訊、事件清單與通知設定
00.01.同一個儲存裝置裡，不同儲存群組的耐用度與健康狀態可能不同。Endurance Group Information 讓主機查一組的警告、讀寫量與容量；Event Aggregate 則把需要注意的群組列出來。本篇把 FID 18h 的逐組設定接到這兩份 log，說明主機如何從一則通知走到具體資料，又如何確認事件而不誤以為問題已經修復。
- Endurance Group
- 耐用度群組；一起管理儲存耐用度的一組容量，可分給零個或多個 NVM Set。
- FID
- Feature Identifier；Get／Set Features 用來選擇查詢或設定功能的代碼。
這篇的主軸
數值的單位與限制
02-01資料量、命令次數、容量各有自己的單位。用實際數字看懂向上取整與「0 表示未回報」，才不會算出不存在的精確值。
設定如何變成待處理清單
03-01逐組選擇警告，再理解清單如何排序、如何編碼長度；識別值、項目序號與 byte 位置各不相同。
通知與確認的先後關係
04-01從 AER 完成結果找到清單，再找到單組資料；比較清除通知、移除項目與警告解除，掌握持續警告的處理方式。
- AER
- Asynchronous Event Request；主機先送出並等待控制器用完成結果回報事件的命令。
00.02.預備知識：OS、Computer Organization 與基本 SSD 概念。Group 7／9、警告值與流量數字皆是說明性範例，並非任何特定裝置的量測結果。
00.03.先學會看懂資料，再走完整的通知流程；必要的 Get Log Page、Get／Set Features 與 AER 欄位會在本文就近說明。
把主軸連起來
00.04.用同一個問題串起全篇：Group 7 的可用備用容量降到 8%，門檻為 10%，而且可靠度下降。主機要能說出：哪些 bit 描述狀態、哪些 bit 選擇通知、清單如何找到 7，以及哪次讀取才算確認這一組的事件。
00.05.健康資料提供現在的狀態與累積統計；事件機制協助主機及時查看。前者不能完整重建通知當時的狀態，後者也不會因為主機已確認事件就修復媒體。
01 先確認正在觀察哪一組儲存空間
01.01.LID 09h 提供指定 Endurance Group 的 512-byte 資料；LID 0Fh 彙整有待處理事件的 Group 識別值；FID 18h 則逐組選擇要回報的警告。三者分別回答「現在如何」、「哪些組需要查看」與「哪些情況需要列入清單」。
- LID
- Log Page Identifier；Get Log Page 用來選擇回覆資料種類的代碼。
來源：Base 2.4 §5.2.13.1.10, 5.2.13.1.15, 5.2.30.1.17
來源：NVME-BASE-2.4, Rev. 2.4, §5.2.13.1.10, 5.2.13.1.15, 5.2.30.1.17, 文件頁 237-239,270,478, PDF 頁 263-265,296,504
01.02.Endurance Group 可以包含分配給零個或多個 NVM Set 的容量。每個 Set 只屬於一個 Group；同 Group 的多個 Set 共同管理耐用度。每個 Group 只屬於一個 domain，16-bit ENDGID 在整個 NVM subsystem 內唯一，0 不是有效 Group 識別值。
- NVM subsystem
- NVM subsystem，包含 controller、port、namespace 與非揮發性儲存資源的 NVMe 系統邊界。
- NVM Set
- 在邏輯上分開的一組非揮發性儲存，可包含數個 namespace。
- ENDGID
- Endurance Group Identifier；本篇用來指定要查詢或設定哪一組的 16-bit 識別值。
- NVM
- Non-Volatile Memory，斷電後仍能保存資料的記憶體。
來源：Base 2.4 §3.2.3
來源：NVME-BASE-2.4, Rev. 2.4, §3.2.3, 文件頁 82-84, PDF 頁 108-110
從管理目的理解分組
01.03.想像同一個裝置提供數個 namespace，主機可以分別讀寫它們，但底層耐用度不一定各自獨立管理。Endurance Group 把「哪些儲存容量一起管理耐用度」明確分組。因此一個 Group 的健康資料，不能直接當成其中單一 namespace 的專屬統計，也不能當成整台裝置所有儲存空間的統計。
把容量與識別值連起來
01.04.本文使用 Group 7／9 作為例子。Group 7 的 Set A、B 可以各有數個 namespace；Group 9 的 Set C 則使用另一份耐用度管理範圍。查詢 Group 7 時，Log Specific Identifier 要放 Group 的 ENDGID=7。編號只用來指定對象，數值 7 不表示容量、清單中第 7 筆或第 7 個 namespace。
- LSI
- Log Specific Identifier；依 log 種類指定對象，LID09h 用它指定 ENDGID。
未配置容量也分層
01.05.Group 內尚未分配給任何 Set 的容量，才是 unallocated Endurance Group capacity。已分給 Set、但 Set 尚未拿來建立 namespace 的容量，仍屬於那個 Set；不能再把它全部加進 Group 的未配置容量。原規格圖中的灰色空間位於哪一層外框內，正是判斷兩者的關鍵。
先查支援，再解讀清單
01.06.Identify Controller 的 CTRATT.EGS bit 4 表示 Endurance Groups 支援；OAES.EGEAN bit 14 表示這類清單變更通知的支援。支援 Group 時必須支援 LID 09h；若 subsystem 支援超過一個 Group，還必須支援 LID 0Fh。只有一組時不能反過來推論 LID 0Fh 一定不支援。未支援 Groups 時，命令中的 Group 欄位被忽略，回傳資料的 Group 識別欄位清 0；這不代表存在 Group 0。
- CTRATT
- Controller Attributes；控制器能力與屬性的位元欄位。
- EGEAN
- Endurance Group Event Aggregate Log Page Change Notices；OAES 中表示支援此通知的位元。
- OAES
- Optional Asynchronous Events Supported；回報控制器支援哪些選用非同步事件。
- EGS
- Endurance Groups；CTRATT 中表示支援耐用度群組的能力位元。
一次記住三個操作的分工
01.07.接下來先學會讀懂單組資料，再設定通知條件，最後沿著通知找到各組的資料。這樣在收到 LID 0Fh 清單時，便知道清單只負責指路，真正的警告、累積讀寫量與容量仍要到 LID 09h 查。
02 讀懂當下警告，不把估計壽命當作故障宣判
02.01.LID 09h 的 EGCW 是處理 Get Log Page 當時的警告狀態，可能已不同於通知發生時。bit 0 表示備用容量低於門檻，bit 2 表示可靠度下降，bit 3 表示整組 namespace 因非寫入保護設定的原因進入唯讀；bit 1 與 bits 7:4 保留。PUSED=100 表示估計耐用度已用完，並不直接表示媒體故障。
- PUSED
- Percentage Used；Group 已使用壽命的廠商估計百分比。
- EGCW
- Endurance Group Critical Warning(s)；在 log 中是警告狀態，在 FID18h 中是選擇哪些警告觸發事件的遮罩。
來源：Base 2.4 §5.2.13.1.10
來源：NVME-BASE-2.4, Rev. 2.4, §5.2.13.1.10, 文件頁 238, PDF 頁 264
02.02.當 subsystem 內所有 Endurance Group 的同一個警告 bit 都是 1，SMART / Health Information 的對應 Critical Warning bit 必須為 1。這條規則不能倒推成「單一 Group 的警告一定代表整個 subsystem 已有相同狀態」。
來源：Base 2.4 §5.2.13.1.10
來源：NVME-BASE-2.4, Rev. 2.4, §5.2.13.1.10, 文件頁 238, PDF 頁 264
先拆 bit，再找數值佐證
02.03.EGCW 不是一個互斥的錯誤代碼，而是可以同時成立的多個警告。05h 的二進位低 4 bits 是 0101b，表示 bit 2 與 bit 0 同時為 1。先列出兩個警告，再用 AVSP 與 AVSPT 檢查備用容量；不要把 05h 讀成「第 5 種錯誤」。
- AVSPT
- Available Spare Threshold；判斷備用容量偏低所用的百分比門檻。
- AVSP
- Available Spare；Group 剩餘備用容量的正規化百分比。
備用空間和已用壽命不能相減
02.04.AVSP=8 表示剩餘備用容量的正規化百分比；AVSPT=10 表示比較門檻。低於是嚴格小於，所以 8<10 符合，10=10 並不符合「低於」這個條件。PUSED 則是廠商依據使用狀況與壽命模型做的估計，不是 100−AVSP。PUSED 可以大於 100，超過 254 的百分比一律以 255 表示；控制器不在 sleep state 時，每個通電小時更新一次。
| 觀察項目 | 本例判讀 | 不能代替的判斷 |
|---|---|---|
| bit0=1；AVSP8 < AVSPT10 | 備用容量低於門檻 | 壽命只剩8% |
| bit2=1 | Group 可靠度下降 | 所有其他 Group 都相同 |
| bit3=0 | 此欄未回報整組唯讀警告 | 所有 namespace 都一定可以寫 |
| PUSED=103 | 已超過估計耐用度的100% | 媒體已故障，或剩餘容量為負 |
唯讀警告有明確原因限制
02.05.EGRO=1 表示這個 Group 的所有 namespace 因其他原因進入唯讀，例如媒體可靠度相關的保護行為。若唯讀完全來自 namespace write protection 狀態的改變，控制器不得因此設定 EGRO。單看「不能寫」的外觀不足以判定 bit 3，還要分清原因。
- EGRO
- Endurance Group Read-Only；非 namespace 寫入保護狀態變更所造成的整組唯讀警告。
警告、歷史次數與通知各有時間意義
02.06.EGCW 回答讀取當時的狀態。累積錯誤次數回答曾經發生多少次。非同步通知則告訴主機曾有需要注意的條件。通知到主機開始讀 log 之間，狀態可能變化；因此收到通知卻讀到 EGCW=0，不能直接判定控制器送了假通知，也不能用這份 log 還原通知當時的全部狀態。
先看局部，再看整體
02.07.假設 Group 7 的 EGDR=1、Group 9 的 EGDR=0，就只確定 Group 7 回報可靠度下降。當兩組都為 1 時，規格才用「所有 Group 同一 bit 皆為 1」的規則要求對應 SMART 警告為 1。SMART log 自身還有其他規則與欄位，不應把單組結果自行擴大成全域結論。
- EGDR
- Endurance Group Degraded Reliability；Group 可靠度下降警告。
03 把累積量、命令次數與容量分開換算
03.01.LID 09h 的 EE、DUR、DUW、MUW 以 1,000,000,000 bytes 為單位並向上取整，0 表示不回報該值。DUR／DUW 不包含控制器內部作業的讀寫，MUW 包含主機與控制器的寫入。HRC／HWC 是已完成命令數；TEGCAP／UEGCAP 是以 bytes 表示的容量，0 同樣表示不回報，不能當作測得的零容量。
- TEGCAP
- Total Endurance Group Capacity；Group 的總 NVM 容量。
- UEGCAP
- Unallocated Endurance Group Capacity；Group 尚未配置給 Set 的容量。
- DUR
- Data Units Read；Group 累積讀取量，不含控制器內部讀取。
- DUW
- Data Units Written；Group 累積寫入量，不含控制器內部寫入。
- HRC
- Host Read Commands；按所用 I/O Command Set 分類的已完成讀取類命令筆數。
- HWC
- Host Write Commands；已完成的 User Data Out 類命令筆數。
- MUW
- Media Units Written；包含主機與控制器內部寫入的 Group 累積量。
- EE
- Endurance Estimate；假設寫入放大為 1 時，Group 全生命週期可寫入量的估計。
來源：Base 2.4 §5.2.13.1.10
來源：NVME-BASE-2.4, Rev. 2.4, §5.2.13.1.10, 文件頁 238-239, PDF 頁 264-265
03.02.以 NVM Command Set 為例，HRC 的命令類別包含 Compare、Copy、Read、Verify；HWC 的 User Data Out 類別包含 Copy、Write。讀取資料不一定把資料傳回主機，寫入資料也不一定由主機傳入；因此 Copy 可以同時涉及兩種統計分類。
來源：NVM Command Set 1.3 §1.4.2.1, 1.4.2.10
來源：NVME-NVM-CS-1.3, Rev. 1.3, §1.4.2.1, 1.4.2.10, 文件頁 10-11, PDF 頁 10-11
先問數字在數什麼
03.03.512-byte 回覆裡放了不同種類的數字。EE 是對總壽命可寫入量的估計；DUR／DUW／MUW 是已發生的累積資料量；HRC／HWC 是命令筆數；TEGCAP／UEGCAP 是可儲存容量。把這四類放在同一個「容量」欄相互比較，會把已使用量、可用空間與工作次數混在一起。
向上取整會留下範圍
03.04.對正數 n，原始 byte 數落在 (n−1)×1,000,000,000+1 到 n×1,000,000,000。讀到 1，不代表恰好寫了十億 bytes，也可能只寫了一部分；讀到 3，才知道超過二十億而未超過三十億。此處的十億是十進位，不是 1 GiB=1,073,741,824 bytes。
| 欄位 | 數值3代表什麼 | 若是0 |
|---|---|---|
| DUR／DUW／MUW | 2,000,000,001～3,000,000,000 bytes | 未回報這項數值 |
| HRC／HWC | 3 筆已完成的對應類別命令 | 計數為0 |
| TEGCAP／UEGCAP | 3 bytes（僅示範單位） | 未回報容量 |
| NUMENT（LID0Fh） | 清單有3筆 | 清單沒有項目 |
- NUMENT
- Number of Entries；清單實際項目數，直接計數。
把主機寫入和媒體工作量對照
03.05.主機寫入資料後，控制器可能為垃圾回收搬移仍有效的資料。DUW 不把這些內部寫入計入，MUW 則計入，因此兩欄能幫助理解內部工作量。可是兩者都已向上取整，小數字的誤差比例很大。用同一觀察時間的非零欄位比較，仍只能得到粗略關係；若任何一欄為 0，就連「有回報量」的前提都不成立。
壽命估計不能直接變成剩餘空間
03.06.EE 是假設寫入放大為 1 時、整個 Group 一生可寫入總 byte 數的估計，不是目前剩餘寫入配額。把 EE−DUW 叫做保證的剩餘壽命沒有依據，也不能拿來替代 PUSED。TEGCAP 則回答 Group 有多少 NVM 容量；UEGCAP 回答其中尚未配置給 Set 的容量，兩者用原始 bytes，沒有十億倍換算。
命令分類和傳輸方向要分開
03.07.以 NVM Command Set 而言，HRC 包含 Compare、Copy、Read、Verify，HWC 則包含 Copy、Write。Compare 比較、Verify 驗證與 Copy 複製都涉及讀取，但不因此把完整讀取資料送回主機；Copy 的目的端寫入也不需要主機重新傳入資料。所以不能只數「有資料傳回主機」的命令來算 HRC，也不能把 HWC 只當成 Write 次數。
命令與錯誤次數要按各自定義讀
03.08.1 筆命令可以搬很多 bytes，所以命令數無法直接換算 DUW。MDIE 計算未恢復資料完整性錯誤；NEILE 計算控制器生命週期內、屬於這個 Group 的 Error Information Log 項目。一次錯誤事件的分類與紀錄方式不同，兩欄沒有必須相等的規則。
- NEILE
- Number of Error Information Log Entries；與該 Group 相關的累積錯誤紀錄項目數。
- MDIE
- Media and Data Integrity Errors；未恢復資料完整性錯誤的累積次數。
04 選擇哪些警告要列入事件清單
04.01.FID 18h 的 CDW11 低 16 bits 指定 ENDGID，bits 23:16 是 EGCW 通知選擇遮罩，逐 bit 對應 LID 09h 的警告。啟用時若條件已成立，也會產生事件。設定保留警告 bit 或指定不存在的 Group，必須以 Invalid Field in Command 中止；ENDGID=0 不表示全體 Group，這時 EGCW 不使用。
- CDW11
- Command Dword 11；命令中的第 11 個 dword 欄位，其內容依命令而定。
- CDW
- CDW（Command Dword）；命令中的 32-bit 欄位單位，例如 CDW10 的 10 是欄位 index，不是 byte offset。
來源：Base 2.4 §5.2.30.1.17
來源：NVME-BASE-2.4, Rev. 2.4, §5.2.30.1.17, 文件頁 478, PDF 頁 504
04.02.Get Features 在 SEL≠011b 且成功時，忽略命令中 EGCW 的輸入，以 CQE DW0 回傳 Figure 493 格式的屬性。SEL=011b 回覆的是 Feature 能力格式，不能當成目前警告選擇。FID 18h 決定逐組列入清單的原因；FID 0Bh 的 bit 14 另外控制清單新增項目時是否通知主機。
- CQE
- Completion Queue Entry；控制器寫入完成佇列的一筆命令結果。
- DW0
- Dword 0；此處指完成項目的第 0 個 dword，內容要配合命令種類與 SEL 解讀。
- SEL
- Select；Get Features 選擇目前值、預設值、保存值或支援能力。
來源：Base 2.4 §5.2.30.1.17, 5.2.12, 5.2.30.1.6
來源：NVME-BASE-2.4, Rev. 2.4, §5.2.30.1.17, 5.2.12, 5.2.30.1.6, 文件頁 210-212,466-467,478, PDF 頁 236-238,492-493,504
同名 EGCW，先看它出現在哪裡
04.03.LID 09h 的 EGCW 是控制器回報的實際狀態。FID 18h 的 EGCW 則是主機設定的選擇遮罩：1 表示對應警告成立時要列入事件清單，0 表示不因這一類警告新增項目。把 mask 設為 0 不會清除 log 的警告，也不會把媒體變健康。
- mask
- 位元遮罩；每個 bit 分別選擇一種條件，可以同時選多種。
用一個完整數字看懂編碼
04.04.本例 bit 2 與 bit 0 都啟用，mask=00000101b=05h。把 mask 左移 16 bits，再加上 ENDGID=7，得到 (05h<<16)|0007h=00050007h。高 8 bits 保留。本篇三種警告全部啟用時是 0Dh，而不是 0Fh，因為 bit 1 保留；對應 Group 7 的完整數字是 000D0007h。
- controller
- controller，實作 NVMe 介面、取走 command 並回報 completion 的控制實體。
- EGEALCN
- Endurance Group Event Aggregate Log Change Notices；FID0Bh 中啟用清單變更通知的位元。
每一組各自設定，不能拿 0 當全部
04.05.Group 7 的設定不會自動套到 Group 9，主機要分別送命令。Figure 493 明確說 ENDGID=0 時 EGCW 不使用，並沒有提供廣播給所有 Group 的語意；此外，章節要求不存在的 Group 識別值使 Set／Get Features 失敗。因此例子一律使用已確認存在的非零 ID，也不把最大識別值以下每個數字都當成存在。
查回設定和查能力是兩次不同解讀
04.06.Get Features FID18h、SEL=0、CDW11=00000007h 查目前屬性。成功時看 CQE DW0 的低 16 bits 確認對象、bits 23:16 讀目前 mask；命令中原先填入的 EGCW 不作設定。若 SEL=3，DW0 低 3 bits 變成 Changeable、NS Specific、Saveable；例如 4 代表可變更而不可保存，絕不能把 4 當作 Group 4。SEL=2 在沒有保存值或不可保存時按預設值處理。
把清單選擇和通知啟用分開
04.07.若需要主動通知，還要在支援的控制器上啟用 FID0Bh 的 EGEALCN bit 14，並提交 Asynchronous Event Request 等待控制器完成回覆。FID18h 是每 Group 的選擇；FID0Bh 是控制器的通知設定。本文只補這個 bit，不改動其他通知選擇。設定後是否跨重設保存，應查 Saveable 能力；Figure 466 的 No 只在該 Feature 不可保存時適用，不能據此宣稱所有裝置都禁止保存。
05 從清單找到 Group，而不是從序號猜 Group
05.01.LID 0Fh 是依 ENDGID 遞增排列的待處理清單，不是事件時間序列。前 8 bytes 是 NUMENT，之後每筆 2 bytes。NUMENT 直接表示筆數；最大筆數受 ENDGIDMAX 限制。超過這份 log 結尾的傳輸資料必須補零；只有 NUMENT 指定的項目才是有效清單內容。
- ENDGIDMAX
- Endurance Group Identifier Maximum；合法 ENDGID 的最大值，不是目前 Group 數量。
來源：Base 2.4 §5.2.13.1.15
來源：NVME-BASE-2.4, Rev. 2.4, §5.2.13.1.15, 文件頁 270, PDF 頁 296
先看筆數，再看識別值
05.02.NUMENT 是 64-bit 直接計數，不採數量減 1。NUMENT=0 表示目前沒有項目；NUMENT=3 就解析 3 個 16-bit ID。清單回答哪些 Group 有啟用且待處理的事件，不提供每組的警告 bit、事件次數或時間戳記。這些不能從列表順序猜出來。
項目序號、位置與 ID 是三件事
05.03.規格以 Entry 1 稱第一筆，位於 bytes 9:8。若程式用從 0 起算的 index i，該筆的 byte offset 是 8+2×i。例子的第 3 筆為 index=2、offset=12、ENDGID=7。12 只是從 log 開頭數過來的 byte 位置；要查細節，必須取出內容 7 作為 LID09h 的 LSI。
- offset
- 偏移量；相對起點的位置。byte offset 以 bytes 計距離，index offset 以項目計位置。
- index
- 索引；本文程式表示法從 0 起算，用來定位清單中的一筆。
| byte位置 | 資料內容 | 讀者應取得的值 |
|---|---|---|
| 0～7 | 03 00 00 00 00 00 00 00 | NUMENT=3 |
| 8～9 | 01 00 | Entry1：ENDGID1 |
| 10～11 | 02 00 | Entry2：ENDGID2 |
| 12～13 | 07 00 | Entry3：ENDGID7 |
| 14～15 | 00 00 | 尾端補零；不是Entry4 |
- Dword
- Dword（Double word）；32 bits，也就是 4 bytes。對比 word=16 bits；例如 zero-based dword count=3 代表 4 個 Dwords，也就是 16 bytes。
- NUMD
- Number of Dwords；此處為 NUMDU 與 NUMDL 合併的數值，Get Log Page 採傳輸 dword 數減 1。
把長度補到可傳輸的單位
05.04.header 是 8 bytes，每筆是 2 bytes，3 筆合計 14 bytes。Get Log Page 以 4-byte dword 為單位，因此要求 4 個 dword，也就是 16 bytes；數量編碼填 3。這份 log 特別規定尾端外的資料補 0，所以不必把多出的兩個零解成額外 entry。這個補零保證不能自行套到所有其他 log page。
- header
- 資料開頭的固定區域；LID0Fh 的前 8 bytes 放 NUMENT。
- entry
- 清單中的一筆項目；LID0Fh 每筆存一個 2-byte Group 識別值。
最大 ID 不是目前筆數
05.05.若 ENDGIDMAX=9，代表合法識別值的上限是 9，實際 Group 數與待處理筆數都可能較少，而且 ID 可以不連續。為清單準備最大空間，可用 8+2×9=26 bytes，再向上補到 28 bytes，NUMD=6。回覆若 NUMENT=3，仍只解析 3 筆；剩餘傳輸空間不是額外 6 組。
分段讀取時不要假設內容凍結
05.06.可以先讀 header 估算資料長度，再讀完整清單；兩個命令之間可能新增或移除項目，因此第二次回覆的 NUMENT 才是該份回覆應使用的筆數。若它超過本次緩衝區可容納項目，就加大後重讀，不能越界解析。這是主機讀取策略；Figure 261 本身沒有提供 generation number，不能聲稱分段資料一定來自同一時刻。
06 走完通知、讀取與確認的完整流程
06.01.成功讀取某 Group 的 LID 09h 且 RAE=0，會清除該 Group 的待處理事件並移除它在 LID 0Fh 的項目。RAE=1 保留事件，讀取失敗也必須保留。讀取 LID 0Fh 且 RAE=0 則清除清單變更通知，不能代替逐組的 LID09h 確認；確認事件不代表造成警告的狀態已消失。
- RAE
- Retain Asynchronous Event；Get Log Page 的事件保留控制，1 保留、0 在成功完成後確認對應事件。
來源：Base 2.4 §5.2.13.1.15, 3.2.3, 5.2.13, 5.2.2
來源：NVME-BASE-2.4, Rev. 2.4, §5.2.13.1.15, 3.2.3, 5.2.13, 5.2.2, 文件頁 84,183-187,213,270, PDF 頁 110,209-213,239,296
06.02.非同步通知透過完成主機預先提交的 AER 回報。此事件的 CQE DW0 為 AET=2、AEI=06h、LID=0Fh，並未包含 ENDGID。持續存在的警告可能在確認後再次被回報；主機宜在確認前調整相應門檻或遮罩，避免相同狀態反覆通知。
- AEI
- Asynchronous Event Information；在事件類型內進一步指出發生哪種事件。
- AET
- Asynchronous Event Type；非同步事件類型，本文使用 Notice。
來源：Base 2.4 §5.2.2
來源：NVME-BASE-2.4, Rev. 2.4, §5.2.2, 文件頁 183-187, PDF 頁 209-213
AER 是主機先留下的通知要求
06.03.主機預先提交 AER；控制器有事件時才完成它。這不是主機每隔幾秒讀一份 log，也不是控制器自行新增主機命令。通知完成後，主機需補送 AER 才能持續接收，未完成數量受 AERL+1 限制；不應替等待事件的 AER 設一般命令逾時。
- AERL
- Asynchronous Event Request Limit；同時未完成的 AER 上限採數量減 1 編碼。
先保留事件，取得要處理的資訊
06.04.收到 CQE DW0=000F0602h，拆成 LID0Fh、AEI06h、AET2，知道要讀彙整清單。以 RAE=1 讀取便能先查看而不確認通知；拿到 Group7 後，再以 RAE=1 查它的 512-byte LID09h。這時讀到的是當下狀態，主機應把有用的數值留下，再決定怎麼處理。
確認有兩個不同對象
06.05.第一個確認對象是「Group7 的待處理事件」：成功讀 09h/7 且 RAE=0，會移除清單裡的 7。第二個是「0Fh 有新增項目」的通知：成功讀 0Fh 且 RAE=0 才清除這個 notice。只做第二步，清單中的 7 仍可能存在；只讀另一組 09h/9，也不會代替 Group7 的確認。
持續警告要先決定是否繼續接收
06.06.若 Group7 的可靠度持續下降，RAE=0 並不修復媒體。主機可以在記錄與處理後，以 FID18h 關閉這一類反覆通知、保留其他警告，再確認事件。這是通知政策的例子，不能把關閉通知稱為修復。日後重新啟用該 bit 時，若條件仍成立，事件會再送出。
把併發更新當作正常運作
06.07.本例為了容易看懂，先假設處理期間沒有新事件；真實運作可能同時有其他 Group 新增項目。最後那次 RAE=0 讀 0Fh 同樣會回傳清單，主機應查看內容，而不是讀完就丟掉。空清單只表示此時沒有列出的待處理項目，不是整台裝置的健康證明；這份格式沒有提供跨多次讀取的原子快照。
07 讀懂本篇的規格圖表
07.01.以下依概念整理規格中的圖表。每組先說明讀取順序與要判斷的問題，接著列出各圖的欄位或行為說明。可以由正文的連結跳到對應組別，也可以用這一節檢查自己能否把欄位連回完整操作。
圖表組 01 · 先確認正在觀察哪一組儲存空間 · 3 張圖表
07.02.先對照三個操作的輸入與輸出，再讀 Figure 69 的外框。能力欄與識別值上限集中在 Figure 338 的必要欄位教學。
回到本節的解釋與範例從外框讀出容量歸屬
07.03.Figure 69 是包含關係示意，顏色與面積不是容量數值，也不是資料移動方向。
| 欄位與位置 | 讀值時要確認什麼 | 具體例子與判斷 |
|---|---|---|
| Endurance Group Y／Z | 虛線外框各包住一個耐用度管理範圍；每個 Group 只屬於一個 domain。 | Y 包含兩個 Set，Z 包含一個；不能據此推論每個 Group 必須相同配置。 |
| NVM Set A／B／C 與 NS | 實線框內的 NS 是 namespace；同一 Set 的儲存屬於相同 Group。 | A1 與 B1 的 namespace 不同，卻都在 Y 的耐用度管理範圍內。 |
| Unallocated 的所在位置 | Group 內、Set 外：未分給任何 Set；Set 內、NS 外：Set 已取得但尚未分給 namespace。 | UEGCAP 對應前者；不可把 A、B 內的灰色空間全部當作 Group 未配置容量。 |
來源：Base 2.4 §3.2.3
來源：NVME-BASE-2.4, Rev. 2.4, §3.2.3, Figure 69, 文件頁 83, PDF 頁 109
Base Figure 69 · NVM Sets and Associated Namespaces
一句話重點
Base69-1外層虛線框決定耐用度管理的範圍，Set 內外的未配置容量不可混加。
來源：Base 2.4 §3.2.3
來源：NVME-BASE-2.4, Rev. 2.4, §3.2.3, Figure 69, 文件頁 83, PDF 頁 109
用例子讀懂
Base69-2原圖 Set A、B 都在 Group Y 內，而 Set C 在 Group Z 內。Y 裡、A／B 外的灰色區才是未分給 Set 的容量；A 內的灰色區雖尚未配置給 namespace，仍然已屬於 Set A。
兩層欄位座標：LSI 裡的 ID、命令裡的 LSI
07.04.Figure 224 定義 LSI 的內容；Figure 205 定義 LSI 在命令中的位置。配合讀一次即可，不必為兩張圖重複解釋同一個 Group。
| 欄位與位置 | 讀值時要確認什麼 | 具體例子與判斷 |
|---|---|---|
| LSI bits 15:0 → ENDGID | 選擇 LID09h 要回覆哪個 Group 的資料，使用有效且存在的 Group ID。 | 0007h 選 Group7；不是 namespace 7，也不是清單第 7 筆。 |
| CDW11 bits 31:16 → LSI | 在命令層級左移 16 bits；低半部保留給 NUMDU。 | (7<<16)|0 = 00070000h。 |
| 固定 512 bytes 的回覆 | 每次取得的是指定 Group 的資料結構；LID 仍在 CDW10 選 09h。 | 從 offset0 取完整資料：128 dwords，NUMD=127。RAE=1 的 CDW10 是 007F8009h。 |
- NUMDU
- Number of Dwords Upper；傳輸數量編碼的高 16 bits。
來源：Base 2.4 §5.2.13.1.10
來源：NVME-BASE-2.4, Rev. 2.4, §5.2.13.1.10, Figure 224, 文件頁 237, PDF 頁 263
Base Figure 224 · Endurance Group Identifier - Log Specific Identifier
一句話重點
Base224-1ENDGID 位於 LSI 內，再由 LSI 放進 CDW11 的高 16 bits。
來源：Base 2.4 §5.2.13.1.10
來源：NVME-BASE-2.4, Rev. 2.4, §5.2.13.1.10, Figure 224, 文件頁 237, PDF 頁 263
用例子讀懂
Base224-2查 Group7：LSI=0007h、NUMDU=0，所以 CDW11=00070000h。Figure 224 的 bits 15:0 是 LSI 內的位置；不能直接把整個 CDW11 填成 00000007h，後者會改到傳輸長度的高半部。
只取本篇需要的 Identify Controller 欄位
07.05.Figure 338 很長；以下列出本篇需要的 byte 位置與 bit。其他能力位元不是保留，也不應被本篇的遮罩檢查清除。
| 欄位與位置 | 讀值時要確認什麼 | 具體例子與判斷 |
|---|---|---|
| CTRATT bytes 99:96，EGS bit 4 | 1 表示支援 Endurance Groups。測試這個 bit，不要求整個 CTRATT 等於 10h。 | CTRATT=30h 仍包含 EGS；另外的 bit 5 不改變 bit 4 的支援判斷。 |
| OAES bytes 95:92，EGEAN bit 14 | 1 表示支援 Endurance Group Event Aggregate Log Page Change Notices。 | OAES 的 00004000h 位元為 1 只表示可支援通知，還要用 FID0Bh 啟用。 |
| AERL byte 259 | 同時未完成 AER 的上限採數量減 1 編碼。 | 3 還原成 4；不是已經發生 3 個事件，也不是要讀 4 筆清單。 |
| ENDGIDMAX bytes 341:340 | 有效 Group ID 的最大值；實際支援的 Group 數小於或等於此值。 | 上限 9 可用來預留 8+2×9 bytes 清單內容，不表示 ID1～9 都存在。 |
| ONCS bytes 521:520，SSFS bit 4 | 控制是否支援 Set Features 非零 SV 與 Get Features 非零 SEL。 | 先確認 SSFS 再使用 SEL=3；支援這個命令欄位，也不代表每個 Feature 都可保存。 |
- ONCS
- Optional NVM Command Support；包含本篇需要的 Save／Select 支援位元。
- SSFS
- Save and Select Feature Support；支援非零 Save 與 Select 欄位值的能力。
- SV
- Save；Set Features 要求保存屬性的控制位元，需確認支援與可保存能力。
來源：Base 2.4 §5.2.14.2.1
來源：NVME-BASE-2.4, Rev. 2.4, §5.2.14.2.1, Figure 338, 文件頁 342-346,353,362,371-372, PDF 頁 368-372,379,388,397-398
Base Figure 338 · Identify – Identify Controller Data Structure, I/O Command Set Independent
一句話重點
Base338-1支援位元、同時等待的 AER 數與 Group ID 上限分別回答不同問題。
來源：Base 2.4 §5.2.14.2.1
來源：NVME-BASE-2.4, Rev. 2.4, §5.2.14.2.1, Figure 338, 文件頁 342-346,353,362,371-372, PDF 頁 368-372,379,388,397-398
用例子讀懂
Base338-2若 EGS=1、EGEAN=1、AERL=3、ENDGIDMAX=9，表示支援相關能力、最多 4 個 AER 同時未完成，以及 Group ID 不超過 9；仍不能宣稱現在有 9 個 Group 或 9 個事件。
圖表組 02 · 讀懂當下警告，不把估計壽命當作故障宣判 · 2 張圖表
07.06.Figure 225 的 byte 0 要逐 bit 看；bytes 3～5 要逐欄區分百分比的意義。下方欄位教學也交代 EGFEAT、DID、保留區與 SMART 對應。
- EGFEAT
- Endurance Group Features；此處用其中的媒體種類 bit 描述 Group。
- DID
- Domain Identifier；表示 Group 所屬的 domain。
只比較警告的對應，不展開整份 SMART log
07.07.Figure 213 本篇只用 byte0 的 bits 0、2、3 來對照 Figure 225。其他欄位有自己的規則，不能把 LID09h 的十億-byte 單位套過去。
| 欄位與位置 | 讀值時要確認什麼 | 具體例子與判斷 |
|---|---|---|
| bit0：ASCBT ↔ EGASB | 兩者都是備用容量低於門檻的警告，分別位於 SMART CW 與單組 EGCW。 | 先確認正在讀的是哪一份 log，再對照同一類警告。 |
| bit2：NDR ↔ EGDR | 可靠度下降的對應位元；所有 Group 都設定同一 bit 時，SMART 對應 bit 必須設定。 | Group7 有、Group9 沒有，不符合「所有 Group」條件。 |
| bit3：AMRO ↔ EGRO | 唯讀條件仍需排除 namespace write protection 狀態變更所造成的唯讀。 | 把軟體設定為唯讀與媒體原因的唯讀分開，不只看最終能否寫入。 |
- EGASB
- Endurance Group Available Spare Below；備用容量低於門檻的警告。
來源：Base 2.4 §5.2.13.1.3
來源：NVME-BASE-2.4, Rev. 2.4, §5.2.13.1.3, Figure 213, 文件頁 221, PDF 頁 247
Base Figure 213 · SMART / Health Information Log Page
一句話重點
Base213-1SMART 的 Critical Warning 和單組 EGCW 有對應 bit，但觀察範圍不同。
來源：Base 2.4 §5.2.13.1.3
來源：NVME-BASE-2.4, Rev. 2.4, §5.2.13.1.3, Figure 213, 文件頁 221, PDF 頁 247
用例子讀懂
Base213-2所有 Group 的 EGDR bit2 都為 1 時，SMART byte0 的 NDR bit2 必須為 1。若只有 Group7 為 1，不能僅憑這條規則就斷言所有 Group 都有可靠度下降。
完整讀懂 512-byte Endurance Group Information
07.08.Figure 225 跨 PDF264～265。先讀前 8 bytes 的狀態，再讀從 byte32 開始的 16-byte 數值。所有 byte 位置都相對本 log 起點；多 byte 整數依低位元組在前的表示方式讀取。
| 欄位與位置 | 讀值時要確認什麼 | 具體例子與判斷 |
|---|---|---|
| EGCW byte 0：bits 0／2／3 | EGASB：備用容量低於門檻；EGDR：重大媒體或內部錯誤造成可靠度下降；EGRO：整組 namespace 因非寫入保護設定的原因唯讀。 | 05h=0101b 表示前兩種警告；0Dh 則連唯讀也成立。這是處理讀 log 當時的狀態。 |
| EGCW 保留 bits 1、7:4 | 不是新的可選警告；不得在 FID18h 啟用其對應 mask bit。 | 0Fh 包含保留 bit1；要選全部已定義警告，使用 0Dh。 |
| EGFEAT byte 1，EGRMEDIA bit 0 | 1 表示資料儲存在旋轉媒體，0 表示不是旋轉媒體；bits 7:1 保留。 | 它描述媒體種類，不是健康程度，也不是警告 bit。SSD 情境不能把 1 解成「SSD 正常」。 |
| AVSP byte 3／AVSPT byte 4 | 剩餘備用容量與其門檻均為正規化百分比；門檻的 101～255 保留。低於門檻才符合此警告條件。 | AVSP8、AVSPT10：8<10；AVSP10 與 AVSPT10 相等，不是低於。 |
| PUSED byte 5 | 廠商估計的生命週期已使用百分比，可超過 100；超過 254 以 255 表示。非 sleep 時每通電小時更新。 | 103 不表示 103% 儲存空間被佔用，也不自動等於唯讀；255 不能反推精確原始百分比。 |
| DID bytes 7:6 | Group 所屬 domain 的識別值；支援多 domain 時必須非零，0 表示不支援多 domain。 | DID=2、ENDGID=7 同時存在不矛盾：一個選管理範圍，一個選範圍內的 Group。 |
| EE bytes 47:32 | 整個 Group 生命週期可寫入 byte 數的估計，假設 write amplification=1；十億 bytes 向上取整，0 不回報。 | EE=1000 是取整後的總壽命估計，不是還可再寫 1000 GB 的保證。 |
| DUR bytes 63:48 | 累積讀取 byte 數，不含控制器內部讀取；十億 bytes 向上取整，0 不回報。 | DUR=2 的區間為 1,000,000,001～2,000,000,000 bytes；垃圾回收內部讀取不另加進此欄。 |
| DUW bytes 79:64 | 累積寫入 byte 數，不含控制器內部寫入；十億 bytes 向上取整，0 不回報。 | DUW=3 不是 3 個 dword、3 個命令或 3 GiB。 |
| MUW bytes 95:80 | 主機加控制器內部寫入總量；十億 bytes 向上取整，0 不回報。 | MUW=5 而 DUW=3 可以反映內部工作量，但取整讓 5/3 不是精確寫入放大率。 |
| HRC bytes 111:96 | 已完成的 Endurance Group Host Read Commands 筆數，成員由所用 I/O Command Set 定義。 | 1000 代表命令計數，不是 1000 GB；不從這個欄位假設每筆長度相同。 |
| HWC bytes 127:112 | 已完成的 User Data Out Commands 筆數，分類同樣由所用 I/O Command Set 定義。 | 一筆搬移更多資料的命令仍是一筆，不能要求 HWC 和 DUW 相等。 |
| MDIE bytes 143:128 | 未恢復的資料完整性錯誤次數，例如無法修正的 ECC、CRC 檢查失敗或 LBA tag 不符。 | 這是累積次數；現在 EGCW 為 0 不會據此把歷史 MDIE 歸零。 |
| NEILE bytes 159:144 | 控制器生命週期內，屬於這個 Group 的 Error Information Log 項目數。 | 計數值 20 不代表現在的 Error Information log 還保留完整 20 筆，也不等於 MDIE 必須為 20。 |
| TEGCAP bytes 175:160 | Group 總 NVM 容量，單位是 bytes；0 表示不回報。 | 1,000,000,000 直接是一十億 bytes，不再乘十億。 |
| UEGCAP bytes 191:176 | Group 中尚未配置給 NVM Set 的 NVM 容量，單位 bytes；0 表示不回報。 | 0 不能證明未配置空間已耗盡；Set 內未建 namespace 的空間也不是本欄的同一概念。 |
| 保留區 byte 2、bytes 31:8、511:192 | 這些位置不提供上述屬性；保留區使下一個欄位仍位於規定的 offset。 | EE 從 byte32 開始，不能因為 DID 在 byte7 結束，就從 byte8 讀 EE。 |
- write amplification
- 寫入放大；為完成主機寫入，媒體還可能承受內部搬移等額外寫入。
- Host
- 主機；執行作業系統並送出 NVMe 命令的一端。
- CRC
- Cyclic Redundancy Check，循環冗餘檢查；由資料位元計算檢查值，以偵測資料變化。
- I/O
- Input/Output，對 namespace 執行資料輸入與輸出的操作類別。
來源：Base 2.4 §5.2.13.1.10
來源：NVME-BASE-2.4, Rev. 2.4, §5.2.13.1.10, Figure 225, 文件頁 238-239, PDF 頁 264-265
Base Figure 225 · Endurance Group Information Log Page
一句話重點
Base225-1先分清狀態、估計、累積量與容量，再按每欄的單位解讀。
來源：Base 2.4 §5.2.13.1.10
來源：NVME-BASE-2.4, Rev. 2.4, §5.2.13.1.10, Figure 225, 文件頁 238-239, PDF 頁 264-265
用例子讀懂
Base225-2同一份資料可以同時有 EGCW=05h、PUSED=103、DUW=3、TEGCAP=1,000,000,000。它們依序是警告遮罩、已用壽命百分比、取整的累積寫入量與精確以 bytes 回報的總容量，不能互相代算。
圖表組 04 · 選擇哪些警告要列入事件清單 · 6 張圖表
07.09.先讀 Figure 493 的高低欄位，再對照 Get Features 的 SEL 與 FID0Bh bit 14。三個設定各有自己的範圍與輸出格式。
回到本節的解釋與範例設定、查回與保存能力放在同一組看
07.10.Figures 493／464／198／201／466 描述同一功能在不同命令階段的欄位；以下共用一次，避免反覆抄同一個 mask 例子。
| 欄位與位置 | 讀值時要確認什麼 | 具體例子與判斷 |
|---|---|---|
| Figure493：CDW11 bits 15:0 | ENDGID 指定存在的 Group；0 時 EGCW 不使用，沒有全體設定語意。不存在的 Group 使 Set／Get Features 必須失敗。 | Group7 與 Group9 分別設定；不用 0 或 ENDGIDMAX 代指全部。 |
| bits23:16：EGCW／bits31:24 保留 | EGCW 的 0／2／3 bits 對應實際警告；啟用保留 bit 必須回 Invalid Field in Command。 | 05h 選兩種；0Dh 選三種；0Fh 多了保留 bit1，無效。 |
| Get Features 的 Figure493 格式回覆 | SEL≠3 且成功時，命令中的 EGCW 不使用；CQE DW0 回屬性。 | 查 Group7 送 CDW11=00000007h，不必在輸入重填目前 mask。 |
| Figure464：CDW10 FID7:0、SV31 | SV=0 不要求保存；SV=1 需控制器支援，且此 Feature 可保存，否則有 Feature Identifier Not Saveable 的規則。bits30:8 保留。 | 本例00000018h 只選 FID18h，不要求持續性；不使用資料 buffer 來傳 mask。 |
| Figure198：CDW10 SEL10:8、FID7:0 | SEL0目前、1預設、2保存、3能力；其他值保留，bits31:11 保留。SEL2 沒有保存值或不可保存時按預設值處理。 | 00000318h 是能力查詢，須先確認 ONCS.SSFS。 |
| Figure201：DW0 bits2／1／0 | CHANG 表可變更、NSSPEC 表 namespace 專屬、SVBL 表可保存。NSSPEC=0 時範圍由 Feature 定義；bits31:3 保留。 | FID18h 的範圍是 Group，不能由 NSSPEC0 推成整個 controller。 |
| Figure466：18h／0Bh 兩列與註腳2 | 18h 是 Group scope，0Bh 是 controller scope；兩者均不使用屬性資料 buffer。No 持續性只在不可保存時解讀。 | 先查 SVBL，再判斷 No 的適用情況；可保存時改看 saved／default／current 的規則。 |
- NSSPEC
- Namespace Specific，指出 Feature 是否具有 per-namespace scope 的 capability bit。
- CHANG
- Changeable，指出 Feature value 是否可由 Set Features 變更的 capability bit。
- SVBL
- Saveable，supported-capabilities result 中指出 Feature 是否可保存的 bit。
來源：Base 2.4 §5.2.12 · Base 2.4 §5.2.12.2 · Base 2.4 §5.2.30 · Base 2.4 §5.2.30.1 · Base 2.4 §5.2.30.1.17
來源：NVME-BASE-2.4, Rev. 2.4, §5.2.12, Figure 198, 文件頁 209-210, PDF 頁 235-236
來源：NVME-BASE-2.4, Rev. 2.4, §5.2.12.2, Figure 201, 文件頁 212, PDF 頁 238
來源：NVME-BASE-2.4, Rev. 2.4, §5.2.30, Figure 464, 文件頁 457, PDF 頁 483
來源：NVME-BASE-2.4, Rev. 2.4, §5.2.30.1, Figure 466, 文件頁 458-459, PDF 頁 484-485
來源：NVME-BASE-2.4, Rev. 2.4, §5.2.30.1.17, Figure 493, 文件頁 478, PDF 頁 504
Base Figure 198 · Get Features – Command Dword 10
一句話重點
Base198-1SEL 改變查詢種類，也可能改變完成結果的格式。
來源：Base 2.4 §5.2.12
來源：NVME-BASE-2.4, Rev. 2.4, §5.2.12, Figure 198, 文件頁 209-210, PDF 頁 235-236
用例子讀懂
Base198-2Get Features CDW10=00000018h 查目前設定；00000318h 查支援能力，前提是控制器支援非零 SEL。兩者都查 FID18h，但不能用同一套 DW0 欄位解碼。
Base Figure 201 · Completion Queue Entry Dword 0 when Select is set to 11b
一句話重點
Base201-1能力回覆的低 3 bits 不包含 ENDGID 或 EGCW。
來源：Base 2.4 §5.2.12.2
來源：NVME-BASE-2.4, Rev. 2.4, §5.2.12.2, Figure 201, 文件頁 212, PDF 頁 238
用例子讀懂
Base201-2SEL3 成功回 DW0=4：CHANG=1、NSSPEC=0、SVBL=0，表示可變更、不是 namespace 專屬且不可保存；0 在 NSSPEC 不代表必然是 controller scope。
Base Figure 464 · Set Features – Command Dword 10
一句話重點
Base464-1SV 決定是否要求保存，FID 才決定要設定哪項功能。
來源：Base 2.4 §5.2.30
來源：NVME-BASE-2.4, Rev. 2.4, §5.2.30, Figure 464, 文件頁 457, PDF 頁 483
用例子讀懂
Base464-2本例採 SV=0，所以 Set Features CDW10=00000018h。不能為了「啟用通知」就把 SV 設成 1；SV 是保存要求，不是啟用 bit。
Base Figure 466 · Set Features – Feature Identifiers
一句話重點
Base466-118h 的範圍是 Group，0Bh 的範圍是 controller；持續性 No 要搭配註腳2。
來源：Base 2.4 §5.2.30.1
來源：NVME-BASE-2.4, Rev. 2.4, §5.2.30.1, Figure 466, 文件頁 458-459, PDF 頁 484-485
用例子讀懂
Base466-2設定 Group7 的 FID18h 不會設定 Group9。若 FID18h 不可保存，表內 No 表示目前值不跨斷電與重設保留；若可保存，該欄不適用，要用保存規則。
兩層選擇的最後一層：是否通知主機
07.11.Figure 474 只取 EGEALCN bit14；其他 bit 是其他事件的選擇，既有設定不應因本篇示例而被清除。
| 欄位與位置 | 讀值時要確認什麼 | 具體例子與判斷 |
|---|---|---|
| EGEALCN bit14=1 | 有 Group 項目新增至 LID0Fh 時，啟用這類主機通知；主機仍需提供 AER 接收。 | 配合 FID18h 才能從指定警告走到通知；不是只開任一個就完成設定。 |
| EGEALCN bit14=0 | 控制器不得送這種清單變更通知；此 bit 不負責清除 Group 的實際警告。 | 主機仍可主動查已支援的 log，輪詢不需要等 AER 完成。 |
| 支援檢查 | 若要求 bit14=1，但 CTRATT.EGS=0 或 OAES.EGEAN=0，必須以 Invalid Field in Command 中止。 | 先測兩個能力 bit，再修改通知設定；支援、啟用與目前事件各自不同。 |
來源：Base 2.4 §5.2.30.1.6
來源：NVME-BASE-2.4, Rev. 2.4, §5.2.30.1.6, Figure 474, 文件頁 467, PDF 頁 493
Base Figure 474 · Asynchronous Event Configuration – Command Dword 11
一句話重點
Base474-1bit14 控制清單新增項目的通知，不取代每 Group 的警告選擇。
來源：Base 2.4 §5.2.30.1.6
來源：NVME-BASE-2.4, Rev. 2.4, §5.2.30.1.6, Figure 474, 文件頁 467, PDF 頁 493
用例子讀懂
Base474-2FID18h 已替 Group7 啟用 mask05h，但 FID0Bh bit14=0，清單仍可記下該組待處理事件；主機沒有因此取得這種新增通知。只在要啟用這一類通知且其他 bit 全0 的例子，CDW11 才是 00004000h。
Base Figure 493 · Endurance Group Event Configuration – Command Dword 11
一句話重點
Base493-1高 8-bit mask 選警告，低 16-bit ID 選 Group；兩者都不是實際健康狀態。
來源：Base 2.4 §5.2.30.1.17
來源：NVME-BASE-2.4, Rev. 2.4, §5.2.30.1.17, Figure 493, 文件頁 478, PDF 頁 504
用例子讀懂
Base493-200050007h 解為 mask05h、Group7。Get Features 的目前值回覆如果也是這個數字，只證明通知設定如此，不表示 Group7 此刻已發生 05h 警告。
圖表組 05 · 從清單找到 Group，而不是從序號猜 Group · 7 張圖表
07.12.Figure 261 的 8-byte header、2-byte entry 與 NUMD 的 4-byte 傳輸單位要分開看。下面也用 512-byte LID09h 對比兩種 log 的長度。
回到本節的解釋與範例讀取命令：先選資料，再設定長度與確認方式
07.13.Figures 204～209 共用這組命令欄位解釋。例子從offset0讀取，以已配置且足夠大的主機接收緩衝區接收資料，不展開記憶體頁描述機制。
| 欄位與位置 | 讀值時要確認什麼 | 具體例子與判斷 |
|---|---|---|
| Figure204：NUMDL31:16／RAE15 | NUMDL與NUMDU合成數量減1。RAE1保留、RAE0成功後確認；若失敗，事件必須保留。 | 512/4−1=127；RAE1不等於取消讀取或少傳1個dword。 |
| LSP14:8／LID7:0 | LID09h與0Fh各選一種資料；沒有定義的LSP是保留。 | 本例LSP0，09h單組、0Fh待處理清單。 |
| Figure205：LSI31:16／NUMDU15:0 | 09h的LSI依Figure224選ENDGID；0Fh未定義LSI選組。NUMDU是NUMD高16bits。 | 512-byte讀取NUMDU0；不得把7填到低半部而誤增傳輸量。 |
| Figure206：LPOL31:0 | OT0表示byte offset低32bits，需4-byte對齊；超過log大小的offset必須失敗。未對齊時可報Invalid Field；若不報，需視低2bits為0。 | 本例全頁讀offset0。定位DUW是byte64；offset7不是合法對齊。 |
| Figure207：LPOU31:0 | offset高32bits，完整位置為LPOU×2^32+LPOL。 | 本篇小型資料以0為高半部，與NUMDU的長度用途不同。 |
| Figure208：OT23、CSI31:24 | OT0是byte；OT1是index，需該log另行支援且定義entry。本篇不假設此能力。09h／0Fh不使用CSI。 | CDW14=0選byte模式；UIDX6:0本例0表示不選UUID，bits22:7保留。 |
| Figure209：09h／0Fh兩列 | 資料為domain／subsystem範圍：多domain時對應接收命令控制器所在domain；單domain時相當於subsystem。CSI欄N表示不使用。 | LID09h內仍用ENDGID選特定Group；scope不是忽略Group選擇。 |
| Restore to Default Content欄 | 09h=N、0Fh=Y；註腳9限定為回復出廠預設內容，不能拿來判斷Feature是否saveable。 | 此欄不定義一般斷電或reset的結果；清單空也不能證明媒體恢復。 |
- NUMDL
- Number of Dwords Lower；傳輸數量編碼的低 16 bits。
- LPOL
- Log Page Offset Lower；讀取起始位置的低 32 bits。
- LPOU
- Log Page Offset Upper；讀取起始位置的高 32 bits。
- UUID
- Universally Unique Identifier，128-bit identifier；其實際關聯範圍仍由使用它的資料結構決定。
- CSI
- I/O Command Set Identifier；選擇 I/O 命令集，NVM Command Set 使用 00h。
- LSP
- Log Specific Field，意義由所選 log page 定義的 command selector。
來源：Base 2.4 §5.2.13
來源：NVME-BASE-2.4, Rev. 2.4, §5.2.13, Figure 204, 文件頁 213, PDF 頁 239
來源：NVME-BASE-2.4, Rev. 2.4, §5.2.13, Figure 205, 文件頁 214, PDF 頁 240
來源：NVME-BASE-2.4, Rev. 2.4, §5.2.13, Figure 206, 文件頁 214, PDF 頁 240
來源：NVME-BASE-2.4, Rev. 2.4, §5.2.13, Figure 207, 文件頁 214, PDF 頁 240
來源：NVME-BASE-2.4, Rev. 2.4, §5.2.13, Figure 208, 文件頁 214-215, PDF 頁 240-241
來源：NVME-BASE-2.4, Rev. 2.4, §5.2.13, Figure 209, 文件頁 215-216, PDF 頁 241-242
Base Figure 204 · Get Log Page – Command Dword 10
一句話重點
Base204-1NUMDL 選傳多少、RAE 選是否確認、LID 選哪種 log，三者不可混讀。
來源：Base 2.4 §5.2.13
來源：NVME-BASE-2.4, Rev. 2.4, §5.2.13, Figure 204, 文件頁 213, PDF 頁 239
用例子讀懂
Base204-2讀512 bytes LID09h、RAE1：NUMDL=127，因此 CDW10=007F8009h。改成007F0009h只把RAE清0，沒有減少回覆資料量。
Base Figure 205 · Get Log Page – Command Dword 11
一句話重點
Base205-1CDW11 上半部的識別值與下半部的長度各有自己的數值。
來源：Base 2.4 §5.2.13
來源：NVME-BASE-2.4, Rev. 2.4, §5.2.13, Figure 205, 文件頁 214, PDF 頁 240
用例子讀懂
Base205-209h/Group7 使用00070000h：LSI7、NUMDU0。0Fh 沒有定義用LSI選單一Group，不能把相同00070000h拿來表示只取清單裡的7。
Base Figure 206 · Get Log Page – Command Dword 12
一句話重點
Base206-1byte offset 是從資料開頭跳過多少 bytes，不能拿 Group ID 當位置。
來源：Base 2.4 §5.2.13
來源：NVME-BASE-2.4, Rev. 2.4, §5.2.13, Figure 206, 文件頁 214, PDF 頁 240
用例子讀懂
Base206-2讀LID09h的DUW可定位byte64；不是因Group7就從offset7開始。要從開頭取完整512 bytes，本例LPOL=0。
Base Figure 207 · Get Log Page – Command Dword 13
一句話重點
Base207-1LPOU 接在 LPOL 上方組成一個位置，不是第二段回覆長度。
來源：Base 2.4 §5.2.13
來源：NVME-BASE-2.4, Rev. 2.4, §5.2.13, Figure 207, 文件頁 214, PDF 頁 240
用例子讀懂
Base207-2LPOL=64、LPOU=0表示byte64；若LPOU=1，位置變成4,294,967,360，已遠超這份512-byte資料。
Base Figure 208 · Get Log Page – Command Dword 14
一句話重點
Base208-1OT 決定位置的單位；本篇用 byte offset，不假設支援 index offset。
- OT
- Offset Type；選擇 offset 以 byte 或項目索引計算。
來源：Base 2.4 §5.2.13
來源：NVME-BASE-2.4, Rev. 2.4, §5.2.13, Figure 208, 文件頁 214-215, PDF 頁 240-241
用例子讀懂
Base208-2本例CDW14=0，OT0表示byte位置。index2的entry位於byte12，不能只把LPOL填2而仍保留OT0；那會變成未對齊的byte位置。
Base Figure 209 · Get Log Page – Log Page Identifiers
一句話重點
Base209-109h 和 0Fh 的資料範圍與回復出廠預設內容的屬性不同，不能因為相鄰就當作相同 log。
來源：Base 2.4 §5.2.13
來源：NVME-BASE-2.4, Rev. 2.4, §5.2.13, Figure 209, 文件頁 215-216, PDF 頁 241-242
用例子讀懂
Base209-2此表09h的Restore to Default Content為N，0Fh為Y。它不是說09h每個欄位永遠不變，而是區分是否回復出廠預設內容；不是一般reset規則。兩列CSI均為N，不用CSI選另一種格式。
用 [1,2,7] 讀出 header、項目與長度
07.14.Figure 261 不包含時間戳記、警告內容或每組事件次數。清單按識別值排序，所以要保留「筆數、位置、內容」三層意思。
| 欄位與位置 | 讀值時要確認什麼 | 具體例子與判斷 |
|---|---|---|
| NUMENT bytes7:0 | 8-byte 直接計數，0 表沒有待處理項目；最大筆數受 ENDGIDMAX 限制。 | NUMENT3 就是 3 筆，不加1；ENDGIDMAX9 不表示本次有9筆。 |
| Entry k，k從1起算 | 規格位置是 bytes(2×k+7):(2×k+6)，每筆是一個16-bit ENDGID。 | k3→bytes13:12，讀出7；最大ID不一定等於筆數。 |
| 程式 index i，i從0起算 | 起點 offset=8+2×i，與規格 Entry k 的 k=i+1 對應。 | i2→offset12；ID7 位於該處，不是 index7。 |
| 傳輸尾端補齊 | 內容8+2×NUMENT bytes；傳輸向上補4-byte整數倍，NUMD=傳輸bytes/4−1。此log尾端外補0。 | NUMENT3→14 bytes→16 bytes→NUMD3；只解析3筆。 |
| 移除單組項目的條件 | 成功讀取那一組 LID09h，且RAE=0；不是只讀彙整清單。 | 09h/7 成功確認後移除7，不代替1或2的處理。 |
來源：Base 2.4 §5.2.13.1.15
來源：NVME-BASE-2.4, Rev. 2.4, §5.2.13.1.15, Figure 261, 文件頁 270, PDF 頁 296
Base Figure 261 · Endurance Group Event Aggregate Log Page
一句話重點
Base261-1NUMENT 決定有幾筆，2-byte 內容才決定要查哪個 Group。
來源：Base 2.4 §5.2.13.1.15
來源：NVME-BASE-2.4, Rev. 2.4, §5.2.13.1.15, Figure 261, 文件頁 270, PDF 頁 296
用例子讀懂
Base261-23 筆清單的 header 是 03 00 00 00 00 00 00 00，後接 01 00、02 00、07 00。第 3 筆起點為 byte12，內容是 7；補到 16-byte 傳輸的尾端零不是第 4 筆。
圖表組 06 · 走完通知、讀取與確認的完整流程 · 2 張圖表
07.15.先沿時序看每次讀取的 LID、ENDGID 與 RAE，再看兩個不同的清除動作。Figure 151／155 解釋通知為什麼不直接告訴你是哪一組。
回到本節的解釋與範例通知的三個欄位，兩個不同的確認對象
07.16.Figures 151／155 只讀本篇Notice的格式與06h這列；其他事件不展開。規格把通知類型與清單中各組事件分開管理。
| 欄位與位置 | 讀值時要確認什麼 | 具體例子與判斷 |
|---|---|---|
| Figure151：AET bits2:0 | 010b表示Notice；bits7:3及31:24保留。 | 000F0602h最低3bits為2，沒有編入Group ID。 |
| AEI bits15:8／LID bits23:16 | AEI06h指明清單新增事件，LID0Fh指定要讀的log。 | 通知可以代表一組或多組新增項目；不能從單一CQE推算NUMENT。 |
| Figure155：Notice06h的確認 | 成功讀0Fh且RAE0清除這個notice，允許之後相關通知繼續被報告。 | 清單中每個Group仍需依09h的規則處理，讀0Fh不是逐組確認的捷徑。 |
來源：Base 2.4 §5.2.2
來源：NVME-BASE-2.4, Rev. 2.4, §5.2.2, Figure 151, 文件頁 184-185, PDF 頁 210-211
來源：NVME-BASE-2.4, Rev. 2.4, §5.2.2, Figure 155, 文件頁 187, PDF 頁 213
Base Figure 151 · Asynchronous Event Request – Completion Queue Entry Dword 0
一句話重點
Base151-1AER 完成值給你事件類型與下一份 log，不含這次是哪個 ENDGID。
來源：Base 2.4 §5.2.2
來源：NVME-BASE-2.4, Rev. 2.4, §5.2.2, Figure 151, 文件頁 184-185, PDF 頁 210-211
用例子讀懂
Base151-2000F0602h 的 bits23:16是0Fh，15:8是06h，2:0是2。低值2表示Notice，不是Group2；要讀0Fh才能知道實際Group。
Base Figure 155 · Asynchronous Event Information – Notice
一句話重點
Base155-1Notice 的 06h 指定清除清單變更通知的方法，與移除單組項目不同。
來源：Base 2.4 §5.2.2
來源：NVME-BASE-2.4, Rev. 2.4, §5.2.2, Figure 155, 文件頁 187, PDF 頁 213
用例子讀懂
Base155-2AET2、AEI06h對應Endurance Group Event Aggregate Log Page Change；成功讀0Fh且RAE0清除此notice。即使讀到[7]並完成這個動作，也還需要09h/7來確認Group7。
學完後想一想
1. DUW=3、MUW=5，能否精確算出主機寫了 3 GB、寫入放大率為 5/3？
08.01.不能。兩欄均以十億 bytes 向上取整，DUW=3 代表大於二十億且不超過三十億 bytes。MUW 也只有區間資訊，因此比值只能作粗略觀察。
來源
來源：NVME-BASE-2.4, Rev. 2.4, §5.2.13.1.10, 文件頁 238-239, PDF 頁 264-265
2. 把 Group 7 的 FID18h mask 從 05h 改成 01h，LID09h 的可靠度警告會自動消失嗎？
08.02.不會。改的是可靠度警告是否觸發新增清單項目；實際狀態由控制器回報。若重新啟用時狀態仍成立，事件可再次回報。
來源
來源：NVME-BASE-2.4, Rev. 2.4, §5.2.30.1.17, 文件頁 478, PDF 頁 504
來源：NVME-BASE-2.4, Rev. 2.4, §5.2.13.1.10, 文件頁 238, PDF 頁 264
3. 清單 [1,2,7] 的 index 2 位於 offset 12，查 LID09h 要用哪個 ENDGID？
08.03.用 7。2 是從 0 起算的項目位置，12 是 byte 距離，7 才是讀出的識別值；此 ID 放進 Get Log Page 的 LSI。
來源
來源：NVME-BASE-2.4, Rev. 2.4, §5.2.13.1.15, 文件頁 270, PDF 頁 296
4. 成功讀取 LID0Fh、RAE=0 後，為何 Group 7 仍在清單？
08.04.這次清除的是清單變更通知。要確認 Group 7 的事件並移除它的項目，須成功讀取 LID09h、ENDGID7、RAE=0；若警告持續，也要考慮再次回報。
來源
來源：NVME-BASE-2.4, Rev. 2.4, §5.2.13.1.15, 3.2.3, 5.2.13, 5.2.2, 文件頁 84,183-187,213,270, PDF 頁 110,209-213,239,296
5. 收到事件卻讀到 EGCW=0，或看到 PUSED=103，分別可以下什麼結論？
08.05.EGCW=0 只說讀取當時沒有該欄位的警告，不能還原通知當時的狀態；103 表示已超過估計壽命的 100%，不直接表示媒體故障或唯讀。兩者都要按欄位本身的時間與定義解讀。
來源
來源：NVME-BASE-2.4, Rev. 2.4, §5.2.13.1.10, 文件頁 238, PDF 頁 264