NVM Set、Endurance Group 與容量

1. 差別在哪裡

支援 NVM Set 時，formatted namespace 完整位於一個 Set；Set 完整位於一個 Endurance Group；Group 完整位於一個 domain。

NVM Set List 回容量與所屬 Group；Endurance Group Log 回其健康與容量；Identify Namespace 回邏輯 block 與歸屬。

2. 如何選擇與確認

查 CTRATT 的 Set／Group 支援與各 List，再讀 namespace 的 NVMSETID、ENDGID。

先畫支援的層級，再填實際 ID。未支援 NVM Sets 時，不要畫出虛構的 Set0 當必要中間層。

例如 EG1 有 Set2、Set3，各有 namespaces；同 Group 的 Sets 由該 Group 共同管理耐用度。

3. 比較時要保留的條件

NVM Sets 支援要求同時支援 Endurance Groups；反方向不成立，Group 可以存在而沒有 Set 功能。

用 namespace、Set、Group 三種查詢確認相同歸屬，避免只看一個名稱相近的 ID。

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

探索以所查 controller 能取得的 subsystem／domain 資訊為準。

查 CTRATT、NSETIDMAX、ENDGIDMAX；再取 NVM Set List 與 Endurance Group List。

Set 屬性有總容量、未配置容量及 ENDGID；Group 的詳細容量和健康需再讀 LID09h。

2. 查詢順序與回覆判讀

先讀能力，再分段列舉有效 ID，最後逐個讀屬性與健康；不要從 1 到最大 ID 全部假定存在。

取得目前物件及歸屬，能分清沒有配置與不支援能力。

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

不支援時輸出的相應 ID 欄位須按規範清零；這不代表真的存在可供指定的有效 ID0。

核對宣告、清單、最大 ID 與 namespace 歸屬的一致性。

先檢查是否把 NSETIDMAX／ENDGIDMAX 誤當成現有總數。

1. 操作前先準備什麼

Create 的歸屬欄位決定新物件所在位置，不是把既有 namespace 搬過去。

查支援的 Lists、可用容量與 LBA Format，再確認 NVMSETID／ENDGID 的組合。

NVM Namespace Create 資料包含 NSZE、NCAP、FLBAS、DPS 與歸屬 ID；NCAP 不得大於 NSZE。

2. 先後順序與完成條件

兩個 ID 都為 0 可由 controller 選擇；指定 Group 而 Set=0 時在該 Group 中選；指定 Set 必須搭配正確的非零 Group。

成功 CQE.DW0 回新 NSID，再讀 allocated Identify 確認實際歸屬；Create 不會自動完成 Attachment。

CQE

Completion Queue Entry，佇列中的完成項目

NSID

Namespace Identifier，邏輯儲存空間識別碼

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

指定不存在或不匹配的組合不能當成自動選擇；須按 Create 的非法欄位／資源錯誤處理。

比對回傳 NVMSETID、ENDGID 與容量扣除的層級，確認不是只建立成功卻查錯物件。

1. 先區分是哪一種失敗

先限定操作是 Namespace Create、Capacity Create/Delete、Get Log 還是 Feature。

例如 Capacity Create Group 的 ELID=0 可自動選 domain；Delete Group 的 ELID=0 則非法。

Capacity Management 非零 ELID 不對應既有物件、Delete 指定 0 或不存在物件，須 Invalid Field；FID18h 指定不存在 Group 也須 Invalid Field。

2. 用哪些資料確認原因

從相應 List 驗證目前有效 ID，再讀該命令欄位的特殊值定義。

先建立合法對照案例，再只換成不存在的非零 ID，避免混入格式、scope 等其他錯誤。

3. 結果與後續驗證

合法自動選擇應成功並回實際 ID；非法明確 ID 不應悄悄改成別的物件。

沒有 Group 支援時，Base 對命令中 ENDGID 有忽略規則；必須先分清未支援功能與已支援但 ID 非法。

先查該命令對 0 的明確定義，不能套一個全域「0 永遠非法」規則。

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

LID09h 以 LSI.ENDGID 選目標，資料涵蓋該 Group 的生命週期。

確認 Group 支援及存在，再讀 512-byte Log。

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

EGCW、AVSP、AVSPT、PUSED 描述健康；DUR、DUW、MUW 描述讀寫量；HRC、HWC、MDIE、NEILE 描述計數；TEGCAP、UEGCAP 為容量 bytes。

先讀健康狀態，再用前後快照比較工作量。此處 DUR／DUW／MUW 用 10^9 bytes 向上取整，不能套 SMART 的 512000-byte 單位。

MUW 包含內部資料搬移，DUW 不含，因此可用來分析額外媒體寫入；仍要考慮取整與 0 代表未回報。

3. 重設或斷電時，要確認什麼

4. 判讀時要保留的條件

沒有回報值不等於真實消耗為 0；不能對分母為 0 或未回報的 DUW 計算有效 write amplification。

Group Log 與 namespace membership、SMART 的整體警告需一致，但不能要求各欄逐 byte 相同。

5. 回報方式與共享對象

健康資料以 Group 為範圍；多個 controllers 可能查看同一資料。RAE 確認也會影響後續事件觀察，需保存讀取者與時間。

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

FID18h 逐 Group 設定，AEC 則控制 aggregate log change 通知。

查 EGCW、AVSP／AVSPT／PUSED、FID18h.EGCW 與 AEC 的相關 notice bit。

EGCW bit0 低 spare、bit2 可靠性降低、bit3 Group 唯讀；namespace Write Protection 不得造成 EGRO。bit1 保留，不能照抄 SMART 溫度 bit。

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

啟用 Group 事件後，有待處理條件就列入 LID0Fh；Host 讀 0Fh 找 ID，再讀各 Group 的 09h。09h 成功 RAE=0 才清該 Group 事件並移除其 entry。

讀 0Fh 確認通知不等於逐 Group 事件全部清除；事件目前已消退時，09h 的 EGCW 也可能已為 0。

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

FID18h 設保留警告 bit 或不存在 Group 須 Invalid Field。

只有全部 Groups 都設相應 warning bit，才依規範要求在整體 SMART 設對應 bit；單一 Group 警告不可直接當成全部媒體唯讀。

先檢查是否只確認 0Fh 就以為 09h 的 Group 事件也已清除。

4. 回報方式與共享對象

Group 事件新增至 aggregate log 後，依 AEC 與 AER 條件通知；FID18h 管哪種 Group 警告加入清單，AEC 管清單變更是否通知 Host。

LID0Fh 回待確認的 Group IDs；LID09h 回指定 Group 的目前健康。成功讀 09h 且 RAE=0，才清除該 Group 的待處理事件。

健康資料以 Group 為範圍；多個 controllers 可能查看同一資料。RAE 確認也會影響後續事件觀察，需保存讀取者與時間。

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

可能分別是 subsystem、domain、Group 或 Set 的容量池。

查 TNVMCAP／UNVMCAP、Domain Attributes、TEGCAP／UEGCAP，以及 Set 的 Total／Unallocated Capacity。

這些實體容量欄位使用 bytes；namespace NSZE／NCAP 使用目前 LBA 格式的 blocks，不能直接把原始數字相減。

2. 查詢順序與回覆判讀

依將執行的管理操作選 Figure89 指定的容量來源，再計入配置粒度與 Capacity Adjustment Factor。

例如 Create Set 從既有 Group 的 UEGCAP 分配，成功不要求 subsystem UNVMCAP 再減一次。

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

零值有時表示未回報，需讀該欄定義與支援條件；不能一律當作沒有容量。

以同一層級的前後數值驗證，避免把不同配置階段相加造成雙重計算。

先明確說出這次要建立的是 Group、Set 還是 namespace。

1. 機制與適用範圍

有 Set 用 Set 容量；無 Set 但有 Group 用 Group；更簡單配置則使用對應 domain／subsystem 容量。

NSZE 描述邏輯大小，NCAP 描述可配置邏輯 blocks；實體消耗還有配置粒度，不必精確等於 NSZE×LBA bytes。

2. 用操作與結果理解

保存 namespace 所屬 ID、LBA 格式、實際 NVMCAP 與該池前後容量。

成功 Create 後查新 namespace 與池餘額；Delete 完成後查清單移除與可重新使用的容量。

容量應依該層級與規則釋出／扣除；Detach 只移除路徑，不能當成 Delete 來預期容量歸還。

3. 容易誤判的地方

容量不足與 NSID 數量耗盡是不同錯誤，不能只看到 Create 失敗就判定 bytes 不足。

NSID

Namespace Identifier，邏輯儲存空間識別碼

把有效資料內容、namespace 存在與容量帳目分開驗證，刪 namespace 也不等於已做資料抹除。

1. 操作前先準備什麼

Group／Set 變更可連帶影響包含的 namespaces 與所有存取路徑。

查 CTRATT 的 Fixed／Variable 與 Delete 支援；Fixed 再讀 Supported Capacity Configuration List。

OPER0 選配置，1／2 建立／刪 Group，3／4 建立／刪 Set，5 恢復預設。ELID 意義隨 OPER 變，CAPU:CAPL 為建立容量 bytes。

2. 先後順序與完成條件

Variable 通常先 Group 再 Set 再 namespace；Fixed 改到另一配置前須依條件清除原配置，不能任意覆蓋正在使用的配置。

Create 成功 CQE.DW0.CELID 回建立的 ID；其他操作不能把同一欄當作永遠有效的物件 ID。

CQE

Completion Queue Entry，佇列中的完成項目

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

刪 Group／Set 會連帶刪子物件；恢復預設前仍有 Group／Set 時須 Command Sequence Error。

完成後重新讀清單、歸屬與容量；操作過程中的中間觀察可能 indeterminate，不宜拿單一中間快照作最終結果。

1. 先區分是哪一種失敗

Create Group 核對 domain／subsystem 可配置量與最大 Group 大小；Create Set 核對 Group 的 UEGCAP。

容量請求使用 CAPU:CAPL bytes，並考慮調整因子與實作配置粒度後所需資源。

容量不足回命令特定 Insufficient Capacity（1/26h）；無可用 ID 回 Identifier Unavailable（1/2Dh）。

2. 用哪些資料確認原因

查 MEGCAP、UNVMCAP、domain 容量、UEGCAP 與目前 ID 清單。

先做只超容量但 ID 尚可用的案例，再做容量足夠但 ID 耗盡的案例，以隔離不同限制。

3. 結果與後續驗證

資源足夠時建立成功且回 CELID；不足時不應假裝建立了不存在的物件。

正文要求 Error.CSINFO 回可建立的最大容量；Figure165 卻寫所需容量，兩處不一致。教材保留這項來源差異，不以其中一個數字直接替韌體判定合規。

先確認失敗的限制種類；涉及 CSINFO 語意時再核對這項規格內部差異。

4. 用 Log 補充哪些證據

容量不足的 Create Group／Set 在支援 Error Log 時，必須記錄明定的 CSINFO 補充容量資訊；其數字語意在正文與 Figure165 有差異，應一併記錄來源。

1. 操作前先準備什麼

依變更層級檢查 Group、Set、namespace、domain 及 Media Unit 歸屬。

保存前後 Identify Lists、容量欄位、Group Log 與受支援的 Media Unit Status。

Create Group 更新 Group List 與上層容量；Create Set 更新 Set List 與 UEGCAP，卻不改 UNVMCAP；刪除則依序移除子物件與回收該層容量。

2. 先後順序與完成條件

先等管理命令完成，再重讀受影響物件；若仍有其他 Host 同時改配置，需記錄時序才能比較。

例如刪 Set 後，其 namespaces 從 allocated list 移除，Media Unit 的 NVMSETID 清零，Group 可用容量增加。

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

操作中間的清單先後更新有明定順序，不能一律要求每個 byte 對所有讀者瞬間原子變更。

用完整變更鏈確認：物件消失、子物件消失、容量回到正確父層、通知讓其他讀者重查。

1. 先界定觸發方式與影響對象

已完成的 Group、Set、namespace 歸屬與容量帳目是比對對象。

保存配置清單、識別資訊、容量及是否有待完成管理操作。

2. 哪些狀態改變，恢復後怎麼處理

Restore Default Capacity Configuration 是另外的 OPER5，並有清空現有物件的先決條件；普通 Reset 不等於這項命令。

恢復命令通道後重新探索，再確認物件與歸屬；對失電時未完成的操作，不假定成功、失敗或 rollback。

已完成配置應能對回原物件，容量差異則需由其他合法管理變更或可說明的狀態解釋。

3. 重設或斷電時，要確認什麼

4. 如何驗證保留或恢復結果

未收到 CQE 只表示 Host 不知道結果，不表示原配置必定完整未改。

先區分「重設造成暫時不可查」與「配置已真正消失」，前者不能直接判成持久性失敗。

先查這段期間是否還執行了 Restore、Delete 或其他容量管理操作。