Namespace Management、Attachment 與保護

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

配置存在於 subsystem；active 存取則以各 controller 為準。

Identify.OACS.NMS=1 表示支援 Management，也必須支援 Attachment；NMS=0 的 controller 仍可能單獨支援 Attachment，應查 Command Effects。

Namespace Management Opcode0Dh，Attachment15h；前者 SEL 選建立／刪除／恢復，後者選 Attach／Detach。

2. 查詢順序與回覆判讀

先確認命令支援，再探索 namespace 與 controller 清單，最後建立需要的管理操作。

宣告 NMS 後，兩種命令及相關變更通知能力應符合要求；單獨 Attachment 支援不代表可建立新 namespace。

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

不支援命令用相應 Opcode 錯誤；支援命令但不支援 Restore Default 操作用 Invalid Field，不能把整個 Management 判成不支援。

交叉比對 OACS、Effects.CSUPP 及合法操作，不只看一個位元。

先確認是否誤把 NMS=0 解成 Attachment 一定不支援。

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

建立新 namespace 會消耗其 NVM Set／Endurance Group 的容量，但尚未附加任何 controller。

查共同 namespace 能力、格式清單、thin provisioning 支援與未配置容量；有 granularity 資訊時一併使用。

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

填 NSZE、NCAP、FLBAS、DPS、NMIC 及需要的資源 IDs。NCAP 不得大於 NSZE；使用小於 NSZE 的 NCAP 需要相應 thin provisioning 支援。

先選格式再換算 blocks。假設 1000 個 4KiB blocks，就是 4000KiB 使用者容量；實際 NVM allocation 可能因配置單位而更大。

Create 成功 CQE.DW0 回 NSID，並以指定屬性格式化；再查 Identify 確認，之後才 Attach。

CQE

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

3. 判讀時要保留的條件

非法格式回 Invalid Format；不支援 thin provisioning 有專屬狀態；資源不足另分容量與 NSID 上限。

比較要求的 blocks／格式與回報的 NSZE／NCAP／NVMCAP，不要求它們有相同單位或數值。

1. 先區分是哪一種失敗

容量依所選資源池判斷，不能把其他 Endurance Group 的剩餘空間直接當成可用。

1/15h 是 Namespace Insufficient Capacity，1/16h 是 Namespace Identifier Unavailable，1/0Ah 是 Invalid Format，1/1Bh 是 Thin Provisioning Not Supported。

沒有遵循 granularity 的偏好倍數可能浪費 allocation capacity，但不應只因未符合偏好就拒絕原本合法的 Create。

2. 用哪些資料確認原因

讀未配置容量、NN／MNAN 的適用定義、格式與 granularity，以及 NVM Set／EG 清單。

以合法基準逐項改參數；容量不足時讀 Error Information.CSINFO 的所需未配置容量 bytes，再決定修正。

3. 結果與後續驗證

拒絕後不能把任意 DW0 當成新 NSID，只有成功 Create 的 DW0 才具有該意義。

比對要求量與真正配置量，區分「格式不允許」與「可用容量不足」。

先查失敗 Status 的完整 SCT／SC，再決定是哪個資源不足。

SCT

Status Code Type，完成狀態代碼類型

1. 操作前先準備什麼

Allocated List 描述適用 inventory；各 controller 的 Active List 可不同。

使用 Identify CNS10h 與新 NSID 的 Identify；Active List CNS02h 用於後續 Attach 驗證。

Create CQE.DW0 回傳 controller 選出的 NSID，不是 Host 預先保證的連號。

2. 先後順序與完成條件

保存建立前清單，等待成功後重新列舉，確認新 ID 出現並可讀其已配置屬性。

新 ID 應在 Allocated List，但不應因 Create 自動出現在任何 controller 的 Active List。

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

清單太長時依 NSID 起點繼續讀；只讀第一頁就說新 ID 不存在可能是 Host 錯誤。

對回 DW0、Allocated List 與 namespace 屬性，避免只用數量增加判斷是哪個物件。

1. 操作前先準備什麼

命令 NSID 指目標 namespace，資料中的 Controller List 指要變更的 controllers。

確認目標已配置、共享能力、controller IDs、Command Set 支援與 MAXCNA／MAXDNA 限制。

SEL0=Attach，1=Detach；傳輸 4096-byte Controller List。List 的 entries 是 CNTLID，不是 NSID。

2. 先後順序與完成條件

建立合法清單，提交並等待完成，再到每個目標 controller 查 Active List 與 namespace 的 Controller List。

成功後只有所列關係變更，namespace 仍在 Allocated inventory 中。

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

Controller List 有非法或 Administrative controller 時回 Controller List Invalid；命令集不支援與未啟用各有不同狀態。

失敗時 Error Information.CSINFO 指第一個失敗 entry 的 byte offset；遇錯後不再處理後續 entries，不能假設整個清單全部回復。

1. 操作前先準備什麼

每個 controller 的 Active List 只代表自己，不能當成 subsystem 全部 namespace。

用 CNS02h 與 CNS12h 等適用 Identify 清單，並核對 controller 身分。

保存 NSID、CNTLID、查詢起點與回傳 entries，避免分頁時漏掉目標。

2. 先後順序與完成條件

Attach 成功後兩個方向都應呈現關係；Detach 成功後兩個方向都不再呈現該附加關係。

例如 namespace7 只附加 A，Attach 到 B 後，B 的 Active 含 7，namespace7 的 Controller List 含 A、B。

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

查詢期間若另有管理操作，清單可能代表不同時間；先停止變更或建立穩定快照，再判矛盾。

Allocated List 在單純 Attach／Detach 前後仍應保留該 namespace，與 active 關係分開比較。

1. 先區分是哪一種失敗

以每個 Controller List entry 當時的附加狀態判斷，可能在前幾項成功後才遇到錯誤。

Already Attached=1/18h，Private=1/19h，Not Attached=1/1Ah，Controller List Invalid=1/1Ch。

Private namespace 已附加一個 controller，附加第二個會因 Private 限制被拒絕；不是因容量不足。

2. 用哪些資料確認原因

讀目前 Controller List、NMIC 共享設定及目標 controller 能力。

一次測一種關係錯誤，收到完成後讀回全部受測 entries，確認第一個錯誤位置與停止處理行為。

3. 結果與後續驗證

合法操作改變指定關係；負向操作回相應狀態，且不處理第一個失敗 entry 之後的 entries。

把 Status、CSINFO offset 與前後清單一起驗證，避免只看整筆命令失敗就認定無任何變更。

先查 namespace 是否為 private，以及是否早已附加。

1. 機制與適用範圍

只改變指定 controller 與 namespace 的關係；其他仍附加的 controller 不因此自動 Detach。

Base8.1.17 將已提交但未完成及後續提交的目標命令，按 inactive NSID 規則處理；再套用各命令明文例外。

2. 用操作與結果理解

保存 outstanding SQID／CID、目標 NSID 與 Attachment 完成時間。

SQID

Submission Queue Identifier，提交佇列識別碼

CID

Command Identifier，同一提交佇列內的命令識別碼

停止新提交，完成需要的資料同步，等待可排空的工作，再 Detach；若刻意測競爭，完整保存命令與狀態轉移順序。

Detach 成功後關係消失；先前已完成的命令不重複完成，未完成者按 inactive 規則處理。

3. 容易誤判的地方

通用 inactive 規則是 Invalid Field，但命令可另有明確例外；不能把所有命令強制寫成同一碼。

確認沒有把已完成的 I/O 誤歸到 Detach 後，也沒有在完成前回收仍可能使用的 buffer。

1. 先區分是哪一種失敗

同一 NSID 仍可在另一個已附加 controller 上 active，因此路徑是判斷的一部分。

對使用 NSID 的命令，Figure93 指定 inactive 預設 Invalid Field；Identify 管理查詢等有自身 selector 規則。

不能把所有成功的 Identify 都當成「Detach 沒生效」，也不能把 inactive 與非法 NSID 的 Status 混用。

2. 用哪些資料確認原因

查該 controller Active List、Allocated List 與 namespace Controller List。

等 Detach 完成，再從已 Detach 的 controller 提交目標命令；對比仍 attached 的 controller，保持其他條件相同。

3. 結果與後續驗證

正常資料存取不能因 namespace 仍存在就繼續視為 active；允許查已配置物件的管理命令則仍可合法工作。

用具體 Opcode／CNS 的規則比對，而不是只看 NSID 相同。

CNS

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

先確認測試送的是 I/O，還是允許查詢 inactive 物件的 Admin 命令。

1. 先區分是哪一種失敗

Delete 移除 subsystem 中的物件，不只是某個 controller 的存取關係。

Management SEL=1 為 Delete，NSID 選既有物件；FFFFFFFFh 表示刪除全部，沒有任何 valid namespace 時此全刪操作仍成功。

特定不存在 ID 依 NSID 類型與命令規則拒絕；不能套用全刪空集合成功的例外。保護或正在清除另有相應拒絕條件。

2. 用哪些資料確認原因

確認 Allocated List、保護狀態、背景操作與影響範圍，再選單一或全部刪除。

停止相關 I/O，建議先從所有 controllers Detach，再 Delete，最後讀回 Allocated／Active lists。

3. 結果與後續驗證

成功後 namespace 不再存在，原附加關係也消失；原 NSID 可能以後重用，不能只用數字當永久身分。

對比刪除前後完整 inventory 與識別資訊，確認沒有僅 Detach 而未 Delete。

先查是否用了 FFFFFFFFh，這會改變空集合的完成語意。

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

Create／Delete 改 inventory；Attach／Detach 改特定 controller 的 Active List。

確認 Attached／Allocated notices 的支援與 AEC，以及 AER 是否可用。

LID04h 列 attached namespace 變更，1Ch 列 allocated 變更；Identify 再查目前狀態，PEL Change Namespace 記錄其定義的管理事件。

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

管理命令完成後處理各受影響 controller 的通知，保存變更清單，再重新 Identify。

Admin Delete 的提交端不回報該次刪除通知；其他符合條件的 controller 仍回報。不能要求每端通知數必須一樣。

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

未啟用通知、事件已遮蔽或已被讀取確認，都會影響可見 AER；不是只用「命令成功卻沒 AER」判錯。

將命令來源、受影響清單與各 controller AEC 放在同一張時間表，避免混淆觀察端。

先查自己是不是處理 Admin Delete 的那個 controller。

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

Create／Delete 影響 Allocated List，Attach／Detach 影響指定 controller 的 Active List。 完整條件見本冊說明

使用 Identify 的 Allocated、Active 與 Controller List 確認目前配置；Changed Attached Namespace List04h 與 Changed Allocated Namespace List1Ch 指出曾變更的 NSID，不能代替完整現況。 完整條件見本冊說明

支援 PEL 時，Namespace Management 對應的 Change Namespace Event06h 記錄建立／刪除等規定事件。 完整條件見本冊說明

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

LID04h 針對該 controller 的 attached namespace 變更，不是整個 subsystem 的通用變更歷史。

查看 LID04h 的固定 1024 個 NSID entry 與讀取／清除規則。

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

超過 1024 個變更 namespace 時，第一筆 FFFFFFFFh，其餘清零，表示不能逐筆列全。

先判斷第一筆是否為溢位標記；若是，重新列舉並讀取需要的 namespace 屬性，不把 FFFFFFFFh 當實際 namespace。

完整重掃能恢復現況；不要求 controller 透過多讀幾次 04h 分頁吐出被省略的全部歷史。

3. 判讀時要保留的條件

Get Log 傳輸截短與清單自身溢位不同；短 buffer 不應被誤判成沒有其他變更。

比較最終 Identify 現況與重掃後 Host 快取，確認溢位後仍能正確同步。

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

已完成的配置與 attachment 保留；未完成命令則需恢復後查實際狀態。

保存 namespace 全球識別、NSID、格式與附加清單，恢復後重新 Identify。

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

Controller Reset、Subsystem Reset 與 Power Cycle 不等於 Restore Default Namespace Configuration；後者是明確管理操作。

恢復 Admin Queue 後列舉既有 namespace，確認附加關係，再建 I/O queues，而不是無條件重新 Create。

原合法配置可恢復存取；Secondary Controller Offline 操作也不應清除 attachment。

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

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

若 Reset 前命令結果未知，清單可顯示已成功的變更；不能只因未收到 CQE 就假設沒有執行。

用持久身分與屬性比對，避免 NSID 重用造成誤配。

先確認 Host 恢復程序有沒有自己做 Restore 或 Delete。

1. 差別在哪裡

多條路徑可指向同一份 namespace 資料，不能把每條路徑當成獨立副本。

Create 時指定 NMIC，Attachment 用 Controller List 操作關係；Shared 仍受 MAXCNA／MAXDNA 等限制。

2. 如何選擇與確認

看 Identify Namespace.NMIC 共享能力與實際 Controller List。

先配置共享屬性，再附加需要的 controllers，逐端查 Active List。

Shared 可由多端存取；Private 從 A Detach 後可再 Attach 到 B，但不能同時保有兩端關係。

3. 比較時要保留的條件

Private 已附加另一 controller 時，新增附加回 Namespace Is Private。

檢查身分、資料與附加關係，避免把多路徑誤算成多份容量。

1. 差別在哪裡

WPS 屬於 namespace，所有附加 controllers 共同執行。

WPS0=未保護，1=Write Protect，2=Until Power Cycle，3=Permanent。一般 Write Protect 可用合法 Set 解除，後兩者不能靠 Set 任意改變。

2. 如何選擇與確認

NWPC 宣告支援模式；RPMB 的 WPC 控制進入 Until Power Cycle 或 Permanent 是否被允許；FID84h 回報實際 WPS。

查能力與進入許可，設定 WPS，等待完成，再 Get 確認。轉入受保護狀態前，controller 須提交該 namespace 的 volatile cache data／metadata 到非揮發媒體。

WPS 與實際禁止改寫的行為一致；Read 仍可依正常條件處理。

3. 比較時要保留的條件

進入未允許狀態或改變 Until Power Cycle／Permanent 回 Feature Not Changeable；multi-domain 不得使用 Until Power Cycle。

WPC 只是進入許可，不是 WPS；把控制位清零不會自動解除既有保護。

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

保留規則跟隨 namespace，不因 controller 更換而解除。

Get FID84h 讀 Current WPS，並記錄實際 Reset 來源及是否有 power cycle。

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

WPS1／3 跨 Reset 與 power cycle 保留；WPS2 跨非 power-cycle 的 CLR 保留，但 power cycle 回 WPS0。

建立基準狀態，執行指定事件，恢復後 Get 並驗證寫入限制；不要把 CC.EN 清零當成拔電。

普通 Controller Reset 後 WPS2 仍受保護，是正確結果；真正 power cycle 後則解除。

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

本 Feature 沒有 Default 值，Get SEL=Default 回 Invalid Field；不能要求一個虛構 Default 來解釋恢復。

同時比對讀回 WPS 與 Write／Format 限制，不只確認 Set 曾成功。

先查測試使用的 Reset 是否真的包含電源循環。

1. 機制與適用範圍

共享 namespace 在所有附加 controller 受保護；Format 或 Subsystem Sanitize 的 scope 若涵蓋它，也不能繞過。

Read／Compare／Verify 等通常允許；Flush 成功且無效果，因進入保護時已提交 cache。Namespace Attachment 允許，但 Delete、Format 或 Sanitize 修改受保護物件會被限制。

2. 用操作與結果理解

查 WPS、命令 scope 與 Figure737 允許清單；不能只檢查 Opcode 名稱。

先算完整影響範圍，再檢查所有受影響 namespace 的 WPS，最後套用命令的附加條件。

允許查詢可正常完成；禁止修改應被拒絕且資料維持受保護，不因換 controller 就成功。

3. 容易誤判的地方

符合禁止修改條件時回 Namespace is Write Protected；不能因 Sanitize 通常忽略 SMART 唯讀警告，就忽略 Host 設定的 namespace 保護。

以同一受保護資料測直接 Write 與跨 namespace 範圍操作，確認 scope 判斷一致。