English 00.01.裝置重設後，如何知道之前發生過什麼？Persistent Event Log 保存跨重設的重要事件，將健康快照、韌體更新、電源、namespace 與設定變更放進共同的紀錄格式。本篇先說明如何讀出同一份資料，再學會把時間、對象、參數與結果連起來，同時分辨紀錄能證明什麼、不能證明什麼。Persistent Event Log持久事件紀錄；保存subsystem重要事件的LID 0Dh紀錄。namespacenamespace，主機透過 controller 存取的一份已格式化非揮發性容量。 這篇的主軸 01這份歷史保存什麼01-01事件種類支援、保存上限與實際內容是三件事。先認識 subsystem 範圍、持久性與遺漏的可能性，避免把有限紀錄當作完整流水帳。 02一次讀取的生命週期02-01建立 context → 讀 header → 分段讀取 → 比對 generation → 釋放。新事件與正在讀的事件集合分開，才能理解為什麼需要context。context本次讀取使用的回報內容與追蹤資訊；建立後新增的事件不加入其中。header資料前端的共同說明區，記載種類、大小、版本等讀取內容所需資訊。 03資料的三層結構03-01外層log header描述整份報告；共同event header描述一筆事件；ED保存該種類的內容。每一層長度和版本各有用途。EDEvent Data，扣除共同header與廠商附加資訊後的事件內容。 04從事件還原合理的關係04-01按健康、時間／重設、儲存變更、清除、硬體及設定分組。一起看對象、動作和結果，不以單一名稱、百分比或時間戳推論成功。 05Base 與 NVM 怎麼接起來05-01Base提供Namespace Change外框，NVM補定FLBAS與DPS。最後再學廠商擴充，遇到未知內容也能辨認範圍並保留原始資料。FLBASFormatted LBA Size，保存格式編號與metadata傳輸方式，不是直接記錄bytes大小。DPSEnd-to-end Data Protection Type Settings，資料保護資訊的類型及位置設定。NVMNon-Volatile Memory，斷電後仍能保存資料的記憶體。 00.02.適合已學過OS、Computer Organization並了解SSD基本概念的讀者。文中的控制器A／B、namespace7及示範數值只用來說明規則，不代表每台裝置都有相同配置。 00.03.中文教學版以循序推理與欄位案例深入學習；中英文post先建立全局觀念，再接續順向Spec報告路徑。主範圍固定為上述兩節，其他來源只補足理解事件所需的欄位。 把主軸連起來 00.04.可以把整篇想成五個連續問題：這台裝置會記什麼；這次讀到哪一份；每筆從哪裡開始；事件內容代表什麼；最後能做出什麼有根據的判斷。前一個問題沒弄清楚，後面的數字就容易讀錯。 00.05.本文用流程圖說明context，用資料區塊圖說明長度，用時間與對象的對比解釋事件。規格欄位很多時採分組表格，共用格式只解釋一次，再由每張圖的獨立案例連回。 01 先分清事件歷史、目前狀態與完整性 01.01.Persistent Event Log（PEL，LID 0Dh）保存 NVM subsystem 的重要事件，跨 power cycle 與 reset 保留。它不是每筆 I/O 的流水帳，也不是永遠不會遺失的完整歷史：容量、同類事件數量、頻率抑制與淘汰策略由廠商決定，Sanitize 也可能移除或修改紀錄。NVM subsystemNVM subsystem，包含 controller、port、namespace 與非揮發性儲存資源的 NVMe 系統邊界。power cycle斷電再上電的電源循環；不等同所有形式的reset。I/OInput/Output，對 namespace 執行資料輸入與輸出的操作類別。LIDLog Page Identifier；指定要讀取哪一種 log page 的編號。PELPersistent Event Log，本篇的持久事件紀錄。來源：Base 2.4 §5.2.13.1.14來源：NVME-BASE-2.4, Rev. 2.4, §5.2.13.1.14, 文件頁 244-245, PDF 頁 270-271 說明性範例01.02.說明性範例：PELS=4 表示最大 256 KiB；本次 TLL=4096、TNEV=9，則只回報 4 KiB、9...
read more
NVMe Persistent Event Log：讀取流程、事件格式與歷史判讀
00.01.裝置重設後，如何知道之前發生過什麼？Persistent Event Log 保存跨重設的重要事件，將健康快照、韌體更新、電源、namespace 與設定變更放進共同的紀錄格式。本篇先說明如何讀出同一份資料，再學會把時間、對象、參數與結果連起來，同時分辨紀錄能證明什麼、不能證明什麼。
- Persistent Event Log
- 持久事件紀錄；保存subsystem重要事件的LID 0Dh紀錄。
- namespace
- namespace，主機透過 controller 存取的一份已格式化非揮發性容量。
這篇的主軸
這份歷史保存什麼
01-01事件種類支援、保存上限與實際內容是三件事。先認識 subsystem 範圍、持久性與遺漏的可能性，避免把有限紀錄當作完整流水帳。
一次讀取的生命週期
02-01建立 context → 讀 header → 分段讀取 → 比對 generation → 釋放。新事件與正在讀的事件集合分開，才能理解為什麼需要context。
- context
- 本次讀取使用的回報內容與追蹤資訊；建立後新增的事件不加入其中。
- header
- 資料前端的共同說明區，記載種類、大小、版本等讀取內容所需資訊。
資料的三層結構
03-01外層log header描述整份報告；共同event header描述一筆事件；ED保存該種類的內容。每一層長度和版本各有用途。
- ED
- Event Data，扣除共同header與廠商附加資訊後的事件內容。
從事件還原合理的關係
04-01按健康、時間／重設、儲存變更、清除、硬體及設定分組。一起看對象、動作和結果，不以單一名稱、百分比或時間戳推論成功。
Base 與 NVM 怎麼接起來
05-01Base提供Namespace Change外框，NVM補定FLBAS與DPS。最後再學廠商擴充，遇到未知內容也能辨認範圍並保留原始資料。
- FLBAS
- Formatted LBA Size，保存格式編號與metadata傳輸方式，不是直接記錄bytes大小。
- DPS
- End-to-end Data Protection Type Settings，資料保護資訊的類型及位置設定。
- NVM
- Non-Volatile Memory，斷電後仍能保存資料的記憶體。
00.02.適合已學過OS、Computer Organization並了解SSD基本概念的讀者。文中的控制器A／B、namespace7及示範數值只用來說明規則，不代表每台裝置都有相同配置。
00.03.中文教學版以循序推理與欄位案例深入學習；中英文post先建立全局觀念，再接續順向Spec報告路徑。主範圍固定為上述兩節，其他來源只補足理解事件所需的欄位。
把主軸連起來
00.04.可以把整篇想成五個連續問題：這台裝置會記什麼；這次讀到哪一份；每筆從哪裡開始；事件內容代表什麼；最後能做出什麼有根據的判斷。前一個問題沒弄清楚，後面的數字就容易讀錯。
00.05.本文用流程圖說明context，用資料區塊圖說明長度，用時間與對象的對比解釋事件。規格欄位很多時採分組表格，共用格式只解釋一次，再由每張圖的獨立案例連回。
01 先分清事件歷史、目前狀態與完整性
01.01.Persistent Event Log（PEL，LID 0Dh）保存 NVM subsystem 的重要事件，跨 power cycle 與 reset 保留。它不是每筆 I/O 的流水帳，也不是永遠不會遺失的完整歷史：容量、同類事件數量、頻率抑制與淘汰策略由廠商決定，Sanitize 也可能移除或修改紀錄。
- NVM subsystem
- NVM subsystem，包含 controller、port、namespace 與非揮發性儲存資源的 NVMe 系統邊界。
- power cycle
- 斷電再上電的電源循環；不等同所有形式的reset。
- I/O
- Input/Output，對 namespace 執行資料輸入與輸出的操作類別。
- LID
- Log Page Identifier；指定要讀取哪一種 log page 的編號。
- PEL
- Persistent Event Log，本篇的持久事件紀錄。
來源：Base 2.4 §5.2.13.1.14
來源：NVME-BASE-2.4, Rev. 2.4, §5.2.13.1.14, 文件頁 244-245, PDF 頁 270-271
02 用 reporting context 取得同一份紀錄
- offset
- 相對指定起點的位移；本篇未另註明時以bytes計算，從0起算。
- GNUM
- Generation Number，用於比較分段讀取前後是否仍是同一代回報內容。
- RCE
- Reporting Context Exists，表示處理命令前是否已存在context。
02.01.Reporting context 固定本次回報的事件集合；之後新增的事件仍須記錄，但不加入既有 context。ACT=1 建立並讀取，已有 context 時失敗；ACT=0 讀取既有 context，沒有時失敗；ACT=2 釋放，沒有也不是錯誤。受支援的 ACT=3 建立或沿用 context，一律回傳 offset 0 的 512-byte header。
- ACT
- Action，Get Log Page中選擇PEL讀取、建立或釋放的動作。
來源：Base 2.4 §5.2.13.1.14
來源：NVME-BASE-2.4, Rev. 2.4, §5.2.13.1.14, 文件頁 245-246,251, PDF 頁 271-272,277
03 從 header 走到每筆事件的邊界
- VSIL
- Vendor Specific Information Length，可選廠商附加資料的byte長度。
- EHL
- Event Header Length，單筆event header中前3 bytes之後的長度。
- VSI
- Vendor Specific Information，共同事件格式中可選的廠商附加資訊。
- EL
- Event Length，事件header之後VSI與ED合計的byte長度。
03.01.LHL 的計數不含前 20 bytes，因此 log header 大小是 LHL+20；EHL 不含事件前 3 bytes，因此事件 header 大小是 EHL+3。EL 已包含 VSIL 指出的廠商資料，事件總大小為 EHL+3+EL，真正 ED 大小為 EL−VSIL。LREV 描述外層格式，ET 與 ETR 決定事件內容的格式。
- LREV
- Log Revision，整份log與共同event header的格式版本。
- ETR
- Event Type Revision，該種類事件內容的格式版本。
- LHL
- Log Header Length，log header中前20 bytes之後的長度。
- ET
- Event Type，事件種類代碼。
來源：Base 2.4 §5.2.13.1.14
來源：NVME-BASE-2.4, Rev. 2.4, §5.2.13.1.14, 文件頁 247-251, PDF 頁 273-277
04 健康、Telemetry 與溫度各留下什麼證據
| 事件 | 保存什麼 | 可以回答什麼 |
|---|---|---|
| 01h SMART | 512-byte健康快照 | 當時的健康與累計量 |
| 0Ch Telemetry | 診斷資料的前512-byte header | 當時捕捉了哪一份資料，邊界為何 |
| 0Dh Thermal | 門檻代碼與相對溫差 | 跨過哪種門檻或改變哪種熱管理狀態 |
- Telemetry
- 控制器或subsystem內部狀態的診斷資料；本篇事件只保存其header。
04.01.ET=01h 保存 512-byte SMART 快照，記錄間隔不得超過 24 power-on hours；ET=0Ch 可保存新建 Telemetry 的前 512 bytes，並不包含完整診斷資料。ET=0Dh 記錄溫度門檻事件，其 OTMP 是相對門檻的 Kelvin 差值，不是絕對溫度。這些都是事件當時的資料。
來源：Base 2.4 §5.2.13.1.14.2.1; 5.2.13.1.14.2.12; 5.2.13.1.14.2.13
來源：NVME-BASE-2.4, Rev. 2.4, §5.2.13.1.14.2.1; 5.2.13.1.14.2.12; 5.2.13.1.14.2.13, 文件頁 252,264-266, PDF 頁 278,290-292
05 韌體、時間戳與重設要連著讀
05.01.Firmware Commit 完成時記錄 ET02，不代表新韌體已啟用；ET04 在 power-on 或 reset 完成後，提供成為有效版本的 FREV 與各控制器資訊。ET03 保存時間戳變更前的 PTSTP，而共同 header 的 ETSTP 是變更後的時間。時間戳可能由重設起算、由主機設定，也可能有停止計時區間。
- ETSTP
- Event Timestamp，共同header內記錄事件發生時間的欄位。
來源：Base 2.4 §5.2.13.1.14.2.2; 5.2.13.1.14.2.3; 5.2.13.1.14.2.4; 5.2.30.1.8
來源：NVME-BASE-2.4, Rev. 2.4, §5.2.13.1.14.2.2; 5.2.13.1.14.2.3; 5.2.13.1.14.2.4; 5.2.30.1.8, 文件頁 252-254,470-471, PDF 頁 278-280,496-497
06 把 namespace 變更接到 NVM 格式欄位
- metadata
- 隨 logical block 儲存的附加資料，可包含資料保護資訊，也可有其他用途。
- PI
- Protection Information，用於檢查資料完整性及關聯資訊的保護資料。
06.01.ET06 記錄成功的 Namespace Management 命令。Base Figure247 定義整體內容與欄位來源；NVM Figure112 補定 byte32 的 FLBAS 與 byte33 的 DPS：建立時取主機指定值，刪除單一 namespace 時取該 namespace 的 Identify 值，刪除全部時這兩個欄位保留。
來源：NVM Command Set 1.3 §4.1.4.4
來源：NVME-NVM-CS-1.3, Rev. 1.3, §4.1.4.4, 文件頁 76-77, PDF 頁 76-77
07 把清除開始、完成與媒體驗證分開
| 看到的紀錄 | 可確認的事 | 還不能說的事 |
|---|---|---|
| 09h Start | 進入清除處理；保存參數與NSID | 清除已完成 |
| 0Eh Media Verification | 已進入媒體驗證；沒有ED | 已成功完成；ED內有NSID |
| 0Ah Completion + SOS3 | 操作已進入失敗狀態 | SPROGFFFFh就等於成功 |
| 0Ah Completion + SOS1 | 此次操作成功完成 | 之後永遠沒有新資料寫入 |
- NSID
- Namespace Identifier，controller 用來指向 namespace 的數值 handle；identifier 不等於 namespace 物件本身。
07.01.ET09 記錄 sanitize 進入處理狀態，ET0A 記錄進入 Idle 或失敗狀態；成功的命令完成不等於長時間清除已完成。ET0E 記錄進入 Media Verification，ETR=1、EL=0，沒有 ED。Start／Completion 的 NSID 指定清除對象，FFFFFFFFh 表示整個 subsystem。
來源：Base 2.4 §5.2.13.1.14.2.9; 5.2.13.1.14.2.10; 5.2.13.1.14.2.14
來源：NVME-BASE-2.4, Rev. 2.4, §5.2.13.1.14.2.9; 5.2.13.1.14.2.10; 5.2.13.1.14.2.14, 文件頁 261-262,266, PDF 頁 287-288,292
08 先選硬體錯誤代碼，再選附加資料格式
08.01.ET05 的 NSHEEC 選擇硬體錯誤種類，AHEI 的格式與長度跟著種類改變。01h～03h 是 PCIe 錯誤資訊，08h 是非預期斷電資訊，0Bh 是控制器就緒逾時資訊；某些種類沒有 AHEI。硬體事件子類的支援由廠商決定，不能把固定的一張表套到所有 ET05。
- NSHEEC
- NVM Subsystem Hardware Error Event Code，ET05內選擇硬體錯誤子類的代碼。
- AHEI
- Additional Hardware Error Information，依硬體錯誤子類選擇格式的附加資訊。
- PCIe
- PCI Express，NVMe memory-based controller 使用的 transport 與裝置互連。
來源：Base 2.4 §5.2.13.1.14.2.5
來源：NVME-BASE-2.4, Rev. 2.4, §5.2.13.1.14.2.5, 文件頁 254-258, PDF 頁 280-284
09 設定事件如何保留命令與資料
- SFEL
- Set Feature Event Layout，指明事件內命令、資料buffer與完成值的位置。
- FID
- Feature Identifier；指定要讀取或設定哪一項 Feature 的編號。
09.01.ET0B 在成功 Set Features、值確實改變且支援記錄時必須記錄；成功但同值時可記錄。Figure252 的 O／P／NR 是各 Feature 在指定控制器類型上的記錄要求，不是該 Feature 的支援能力。SFEL 決定連續 CDW、可選資料 buffer 與可選 CQE DW0 的位置。
- CQE
- Completion Queue Entry，CQ 中的一筆完成結果資料結構。
- P
- Phase Tag，讓 host 判斷 CQ slot 是否包含新 completion 的翻轉 bit。
來源：Base 2.4 §5.2.13.1.14.2.11
來源：NVME-BASE-2.4, Rev. 2.4, §5.2.13.1.14.2.11, 文件頁 262-264, PDF 頁 288-290
10 識別值映射與廠商擴充如何讀到正確邊界
10.01.ET10 記錄 Exported NVM Subsystem 的建立、刪除或實體變更；OTYP 決定 EEID／UEID 代表namespace、controller、port或其他對象。ETDE 的 ED 是一串廠商資料描述子，每筆長度為6+VSEDL，依VSEDT選資料型別；廠商事件與任何事件皆可能有的VSI並不是同一層。ETDF的內容格式由TCG保留定義。
- controller
- controller，實作 NVMe 介面、取走 command 並回報 completion 的控制實體。
- TCG
- Trusted Computing Group；此處Base把特定安全事件內容保留給其定義。
來源：Base 2.4 §5.2.13.1.14.2.16; 5.2.13.1.14.2.17; 5.2.13.1.14.2.18
來源：NVME-BASE-2.4, Rev. 2.4, §5.2.13.1.14.2.16; 5.2.13.1.14.2.17; 5.2.13.1.14.2.18, 文件頁 267-270, PDF 頁 293-296
開著 Spec 的順向報告路徑
R-1用上面的全貌與案例先講清楚問題，再依PDF檢視器頁碼往後讀。Base完整走完這一節後，只切一次到NVM；中文教學已解釋必要引用，不需要為每個欄位來回翻頁。
| 頁碼順序 | 起點標題 | 講解重點與停止位置 |
|---|---|---|
| R1 · Base PDF 270–272 | 5.2.13.1.14 | 先講保存範圍與限制，再沿ACT四種動作說明context生命週期。270頁從本節標題開始，略過前面的ANA表尾。 停止於 Figure233 之前。 |
| R2 · Base PDF 273–277 | Figure233 | 由log header走到共同event header，再用ECRH與事件類型表收束。只讀本篇範圍內的欄位。 停止於 5.2.13.1.14.2.1 之前。 |
| R3 · Base PDF 278–284 | 5.2.13.1.14.2.1 | SMART快照→韌體→時鐘→重設→硬體。先說每種事件能證明什麼，再看該種附加資料。 停止於 5.2.13.1.14.2.6 之前。 |
| R4 · Base PDF 284–290 | 5.2.13.1.14.2.6 | Namespace、Format、Sanitize與Set Feature，再到Telemetry。Figure247的FLBAS／DPS先說用途，最後切NVM時補格式。 停止於 5.2.13.1.14.2.13 之前。 |
| R5 · Base PDF 291–296 | 5.2.13.1.14.2.13 | 溫度、Media Verification、Personality、實體映射與廠商描述子。296頁讀完TCG事件段落，在下一log標題前停止。 停止於 5.2.13.1.15 之前。 |
| R6 · NVM PDF 76–77 | 4.1.4.4 | 只切一次文件，從Persistent Event Log標題讀到Figure112，補齊Create／單一Delete／Delete All的FLBAS與DPS來源。 停止於 4.1.4.5 之前。 |
- ECRH
- Establish Context and Read Header，支援ACT3及GNUM的能力位。
- ANA
- Asymmetric Namespace Access；描述同一 namespace 經不同 controllers 存取時的路徑狀態。
學完後想一想
1. ACT3成功回RCE=0，要再送ACT1才能讀事件嗎？
12.01.不需要。RCE0表示命令處理前沒有context，ACT3已建立並回header；接續用ACT0。這時再送ACT1，反而因已有context而得到Command Sequence Error。
來源
來源：NVME-BASE-2.4, Rev. 2.4, §5.2.13.1.14, 文件頁 245-246,251, PDF 頁 271-272,277
2. EHL21、VSIL4、EL20時，事件是44還是48 bytes？
12.02.44。EHL+3是24-byte header；EL20已含4-byte VSI，ED只剩16。48把VSI算了兩次，會錯過下一筆的開頭。
來源
來源：NVME-BASE-2.4, Rev. 2.4, §5.2.13.1.14, 文件頁 247-251, PDF 頁 273-277
3. PEL的Telemetry header寫Data Area3有9個blocks，這筆事件含那些資料嗎？
12.03.不含。ET0C只複製前512 bytes header，提供當時的邊界、原因和generation等資料；不能當成完整Telemetry內容，也不保證現在還能取得相同版本。
來源
來源：NVME-BASE-2.4, Rev. 2.4, §5.2.13.1.14.2.1; 5.2.13.1.14.2.12; 5.2.13.1.14.2.13, 文件頁 252,264-266, PDF 頁 278,290-292
4. 事件byte32=12h就能說這份namespace每個LBA有18 bytes嗎？
12.04.不能。有效FLBAS裡12h代表format index2與延伸LBA metadata，不是大小18。還要先確認操作不是Delete All；實際資料與metadata大小來自所選格式定義。
來源
來源：NVME-NVM-CS-1.3, Rev. 1.3, §4.1.4.4, 文件頁 76-77, PDF 頁 76-77
來源：NVME-NVM-CS-1.3, Rev. 1.3, §4.1.5.1; 4.1.6, 文件頁 85-87,112-113, PDF 頁 85-87,112-113
5. Sanitize completion事件的SPROG=FFFFh，是否能證明已成功清除？
12.05.不能。先讀SOS；例如SOS3就是失敗。FFFFh也用在非處理狀態與Media Verification，這不是一個可獨立判斷成功的百分比。
來源
來源：NVME-BASE-2.4, Rev. 2.4, §5.2.13.1.14.2.9; 5.2.13.1.14.2.10; 5.2.13.1.14.2.14, 文件頁 261-262,266, PDF 頁 287-288,292
來源：NVME-BASE-2.4, Rev. 2.4, §5.2.13.1.38, 文件頁 314-316, PDF 頁 340-342
6. 找不到某次設定事件，就能說主機沒改過設定嗎？
12.06.不能。先看該Feature的記錄政策與支援；有些禁止用ET0B記錄，有些是選用或不建議。再考慮容量淘汰、頻率抑制，以及目前context是否早於那次變更。
來源
來源：NVME-BASE-2.4, Rev. 2.4, §5.2.13.1.14.2.11, 文件頁 262-264, PDF 頁 288-290
來源：NVME-BASE-2.4, Rev. 2.4, §5.2.13.1.14, 文件頁 244-245, PDF 頁 270-271
來源：NVME-BASE-2.4, Rev. 2.4, §5.2.13.1.14, 文件頁 245-246,251, PDF 頁 271-272,277
Comments