資料 I/O：長度、持久性與完整性

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

本題限定一般 Read／Write，先假設無其他命令擴充。命令作用於 NSID 指定的 namespace；MDTS 限制 Host 與 controller 之間的資料傳輸，NSZE 則界定合法 LBA，兩者衡量的對象不同。

NSID

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

Identify Controller 提供 MDTS 與 CTRATT.MEM，CAP.MPSMIN 提供最小記憶體頁面大小；Identify Namespace 提供 NSZE、目前 LBA Format、LBADS、MS 及 metadata 配置。MDTS 非零時，上限為 2^MDTS × 2^(12+MPSMIN) bytes，不能改用目前 CC.MPS。

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

SLBA 是起始位址；Read／Write 的 NLB 採 zero-based 編碼，所以實際區塊數為 NLB+1，最後一個 LBA 為 SLBA+NLB。LBADS 表示每個資料區塊有 2^LBADS bytes。若 metadata 與資料交錯傳輸且 MEM=0，MDTS 計算需包含 metadata；MEM=1 則排除 metadata。

SLBA

Starting LBA，起始邏輯區塊位址

先固定 namespace 格式並計算 LBA 範圍，再算實際傳輸 bytes，最後才配置 PRP／SGL。教學假設 MPSMIN=0、MDTS=5、資料 4096 bytes、交錯 metadata 8 bytes（本例不使用 PI）、MEM=0：NLB=31 代表 32 個區塊，需傳 131328 bytes，超過 131072-byte 上限；只算使用者資料就會漏掉 256 bytes。

PRP

Physical Region Page，描述資料頁位置的指標

SGL

Scatter Gather List，描述分散資料區段的清單

在同一假設下，31 個區塊需 127224 bytes，可以符合 MDTS；命令的 NLB 應填 30。這只證明長度條件成立，還要滿足 NSID、存取權限、指標與 PI 等條件，成功 CQE 才代表這次 I/O 正常完成。

NSID

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

CQE

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

3. 判讀時要保留的條件

超過 MDTS 會以 Invalid Field in Command（SCT/SC=0/02h）中止；LBA 範圍超過 NSZE 則是 LBA Out of Range（0/80h）。例如 NSZE=1024、SLBA=1000、NLB=31，最後 LBA=1031，已超過 1023。驗證特定錯誤時，一次只留下其中一種違規。

SCT

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

MDTS=0 只表示沒有 MDTS 這項上限，不會取消 NLB 的編碼範圍、namespace 邊界或命令專屬限制。也不能把 MDTS 直接套到不傳送 Host 資料的 Verify、Write Zeroes 或 Write Uncorrectable。

1. 操作前先準備什麼

Write.FUA 作用於該筆命令的資料及 metadata。Flush 則作用於指定 namespace 中，在 Flush 提交前已由 controller 完成的命令；它不是自動排序其他仍在執行中命令的全域屏障。

先確認 VWC.VWCP 是否有揮發性快取、FID06h.WCE 是否啟用，以及 VWC.FB 是否允許 Flush 的 NSID=FFFFFFFFh。namespace 的 VWCNP 也可能指出該 namespace 沒有揮發性快取，不能只看 controller 的整體宣告。

Write 的 FUA=1 要求其資料及 metadata 在命令完成前提交至非揮發媒體；FUA=0 本身不增加要求。Flush 使用 NSID 選範圍，其他命令專屬欄位為 Reserved。FB=11b 才表示廣播 Flush 涵蓋提交端已附加的 namespaces。

2. 先後順序與完成條件

要保證一組已提交寫入的持久性，Host 可先等所有目標 Write 成功，再對正確 NSID 提交 Flush，最後等 Flush 成功。假設 Write A 與 Flush 同時提交，不能因 Flush 比 A 先完成，就宣告 A 已被涵蓋。另一種做法是讓各筆 Write 自己帶 FUA=1，並等待各筆成功。

符合範圍與先後條件的 Flush 成功後，所涵蓋資料須具備持久性。沒有或未啟用揮發性快取時，Flush 沒有效果；若也沒有進行中的 Sanitize，仍須成功完成。這不是不支援 Flush 的錯誤。

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

FB=10b 時使用 NSID=FFFFFFFFh，須回 Invalid Namespace or Format（0/0Bh）；Base 2.4 controller 不得用 FB=00b 的舊版未定義廣播行為。進行中的 Sanitize 有自己的命令限制，不能把平常無快取時的成功要求直接套過去。

FUA 與 Flush 不會增加原子寫入單位。原子性限制中斷或競爭時可觀察到哪些資料組合；持久性則約束成功後是否可因失電退回舊資料。應把命令時間線、Current.WCE、FUA 與 Flush 的涵蓋範圍放在一起判讀。

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

正常原子性限制與其他 Read／Write 交錯時可見的結果；斷電原子性則限制寫入被失電或錯誤中斷時的新舊資料組合。本題的兩種保證都不是「成功之後必定持久」的替代說法。

先查 NSFEAT.NSABP 與 MAM。NSABP 決定 namespace 的 NAWUN／NAWUPF 是否有效；有效欄位若為 0，表示退回 controller 的 AWUN／AWUPF，非零值則按 zero-based 編碼加 1。MAM=0 是 Single，MAM=1 是 Multiple Atomicity Mode；正常原子性另確認 FID0Ah.DN 沒有解除該要求。

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

NABSN 與 NABSPF 分別定義正常及斷電邊界大小；0 表示沒有這項邊界，非零編碼需加 1 才是區塊數。NABO 是第一個邊界的 LBA，不是數量欄位。解碼後的邊界位置為 NABO+y×邊界大小，y 為非負整數。

教學假設 NSABP=1、MAM=0、DN=0、AWUN=AWUPF=0、NAWUN=7、NAWUPF=1、NABSN=NABSPF=15、NABO=0。正常單位是 8 個區塊，斷電單位是 2 個，邊界每 16 個區塊出現。Write 範圍 14～15 沒有跨界；改成 15～16 便跨過 LBA16。

正常完成的 Write 回報 Success；但若要驗證中斷時的原子性，還需讀回資料。前例 14～15 的 2-block Write，在符合斷電原子性前提且被中斷時，後續讀回須是整組舊資料或整組新資料，不能一個新、一個舊。15～16 則沒有這項整筆 2-block 保證。若另採合法的 Multiple Atomicity 配置，跨界命令按邊界拆成各自原子的子範圍，仍不等於整筆一起原子更新。

3. 判讀時要保留的條件

一般 Write 超過原子單位或跨界，不代表 controller 一定要拒絕；命令仍可能成功，只是保證範圍不同。不能將 fused Compare-and-Write 的 Atomic Write Unit Exceeded 條件，直接套到所有 Write。

Format 後應重新取得 namespace 的原子欄位，不能沿用舊格式下的 bytes 換算。若同時測試其他寫入者，還要保留命令交錯證據；單次剛好讀到完整新資料，只證明這次結果，不能證明超出規範宣告的更大原子單位。

1. 差別在哪裡

三者都指定 namespace 與 LBA 範圍，但資料方向不同。Compare 的 buffer 由 Host 傳入，Read 的 buffer 接收資料，Verify 則沒有這份 Host 資料傳輸；不能用相同 buffer 期待三者留下同樣結果。

SLBA／NLB 選範圍，PRCHK 選要檢查的 PI。Compare 的非 PI metadata 也參與比對，PI 則依檢查規則處理。Verify 的 PRACT 必須為 0；其 FUA=1 要求先提交相關快取，再對已提交至非揮發媒體的內容執行 Verify，仍不建立其他命令的提交順序。

2. 如何選擇與確認

先查對應 Opcode 的支援宣告與 Commands Supported and Effects。Verify 的大小需另外讀 VSL 及 ONCS.NVMVFYS：非零 VSL 搭配該支援位元，可表示建議最大值，而非一律拒絕超限。MDTS 不直接限制沒有 Host 資料傳輸的 Verify。

教學假設 LBA100 的正確內容是 A。先等寫入 A 完成，Read 取得 A；Compare 的輸入 A 應可成功，輸入不同的 B 應得到 Compare Failure。Verify 只檢查所存資訊是否可通過完整性檢查，所以即使應用程式原本想存 B，它仍可能成功。

Read Success 配合收到的 bytes，才可確認讀回內容；Compare Success 證明選定範圍與提供的比較資料相符；Verify Success 證明執行了所要求的完整性檢查。若有其他 controller 同時改寫同一範圍，三次不同時點的結果不能直接互相比較。

3. 比較時要保留的條件

內容不符使用 Compare Failure（2/85h），不等於 Unrecovered Read Error（2/81h）。Verify.PRACT 非零須回 Invalid Field（0/02h）；已偵測到的 PI 錯誤另用對應的資料完整性 Status。規範不要求同一媒體問題讓 Verify 與 Read 回傳完全相同的錯誤代碼。

Verify 沒有把資料送回 Host，但其讀取或檢查的資料仍須計入 SMART 的 Data Units Read。這個計數表示規範定義的工作量，不代表 Host 一定收到那些 bytes。比對時也要考慮計數的單位與向上取整。

4. 用 Log 補充哪些證據

Verify 的讀取及完整性檢查工作須計入 Data Units Read，即使沒有 Host 資料傳輸。錯誤細節仍依 CQE 的 More 及 Error Information 規則關聯；不是每次正常檢查都新增 Error entry。

1. 差別在哪裡

本題比較指定 namespace 中的 LBA 範圍，先以 NSZ=0 的一般 Write Zeroes 為例。整個 namespace 清零的 NSZ=1 有額外條件，不可用普通範圍操作的成功去推論一定支援。

Write Zeroes 的 NLB 採 zero-based，DEAC 表示 Host 是否請求解除配置；Dataset Management 的 NR 也是 zero-based，但每筆 Range 的 Length in Logical Blocks 是 1-based 數量。兩種命令都需區分「欄位的編碼」與「實際處理多少區塊」。

2. 如何選擇與確認

先查 Write Zeroes／Dataset Management 支援、namespace 的 DLFEAT.DRB 與 NSFEAT.DAE，再讀 FID05h.DULBE。DRB 描述解除配置後的讀取值；DAE 表示能否回報解除配置或未寫入錯誤；DULBE 決定是否啟用該錯誤。

教學假設 DRB=001b、DAE=1，先完成一筆合法 Write Zeroes，再讀同一範圍。若 controller 有解除配置且 DULBE=1，Read 應回 Deallocated or Unwritten Logical Block；若 DULBE=0 且讀取成功，則回全零。DEAC=0 也不代表禁止 controller 在仍能保證全零讀值的情況下解除配置。

不能把「Write Zeroes 後 Read 得到 DULBE 錯誤」直接判成清零失敗。另一方面，Dataset Management Success 也不能證明每個範圍真的被解除配置；其處理限制與允許不採取動作的規則，需和讀回結果分開判讀。

3. 比較時要保留的條件

已解除配置或未寫入，且錯誤已受支援並啟用時，適用 Read 類命令須回 Deallocated or Unwritten Logical Block（2/87h）。若 NSZ=1 但 DEAC=0，或 namespace 不支援解除配置後回全零，Write Zeroes 須回 Invalid Field（0/02h）。

DULBE 停用時，真正已解除配置的區塊按 DRB 回全 00h 或全 FFh；DRB=000b 可為其中之一，但同一區塊在再次寫入前必須保持確定的讀值。Read 或 Verify 不會把該區塊變回已配置。

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

本題限定 16-bit Guard、STS=0、Type 1 的 8-byte PI 範例；不把這個位元配置套到 32-bit 或 64-bit Guard。Guard 占 2 bytes，Application Tag 占 2 bytes，Reference Tag 占 4 bytes，三者位於該區塊的 metadata。

Identify 的 DPC 告訴你支援哪些保護配置，DPS 表示目前使用的保護類型，LBA Format 的 MS 表示 metadata 大小；另確認使用中的 PI Format 與 STS。只查支援能力，卻沒查目前格式，可能會拿錯長度或錯誤 tag 配置來驗證。

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

PRCHK 的 bit2、bit1、bit0 分別控制 Guard、Application Tag、Reference Tag 檢查；PRACT 控制 PI 的傳遞、產生或移除。本題啟用 Reference Tag 檢查時，Type 1 的 ILBRT／EILBRT 必須符合 SLBA 的低位元；Application Tag Mask 中的 1 表示要比較該位元，0 表示遮蔽。

教學假設資料 4096 bytes、MS=8、PRACT=0、PRCHK=111b，先準備正確 PI，並避免 Application Tag=FFFFh 這個免檢查值。先確認合法案例成功，再分別只改 Guard、Application Tag 或 Reference Tag，並保持其他欄位及資料不變，才能分辨是哪項檢查回報錯誤。

合法基準案例應成功完成；Read 的資料與 metadata 則依 PRACT 決定傳回內容。在此格式且 MS=8 時，Write.PRACT=1 由 controller 產生並附加 PI，Host 不提供那 8 bytes，PRCHK 會被忽略；Read.PRACT=1 則先按條件檢查，再移除 PI，只把資料交給 Host。若 MS 大於 PI 大小，不能再假設整份 metadata 都從 Host buffer 消失。

3. 判讀時要保留的條件

已啟用且未被特殊值停用的檢查，失敗時分別回 Guard 2/82h、Application Tag 2/83h、Reference Tag 2/84h。本題若啟用該檢查，而 Type 1 命令中的 ILBRT／EILBRT 本身不符合 SLBA，則屬 Invalid Protection Information（1/81h）；這和資料中存放錯誤 tag 是不同條件。

Type 1／Type 2 的 Application Tag=FFFFh 會停用 PI 檢查，即使 PRCHK 已開啟。因此，「故意放錯 Guard 卻成功」可能是 PRACT 讓 controller 重建 PI，或 tag 的特殊值停用了檢查；不能直接判定 controller 沒做資料保護。

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

本題先限定同一 namespace、Copy Descriptor Format 0h 的範例。NSID 指向目的 namespace，SDLBA 指向目的起點；來源範圍由 descriptor 順序排列。跨 namespace 的 Formats 2h／3h 還有額外規則，不能只換一個 NSID 就照抄。

先確認 Copy 與 descriptor format 的支援，再讀 MSRC、MSSRL、MCL。MSRC 採 zero-based，限制來源範圍筆數；MSSRL 限制單一來源的區塊數；MCL 限制全部來源的總區塊數。目的端的原子單位另行限制可獲得的寫入原子性。

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

命令的 NR 與每筆來源 NLB 都採 zero-based，先解碼再加總。教學假設 NR=1，兩筆來源 NLB 分別是 3 與 1，表示 4+2 個區塊；若 SDLBA=1000，依序寫入 1000～1003 與 1004～1005，而不是各自從 1000 開始。

先確認來源與目的範圍有效、未重疊且符合三項 Copy 限制，再保留來源快照與目的舊內容。失敗時讀 CQE.DW0，將其解釋為「最低編號、未成功複製的 Source Range entry」，而非成功區塊總數或下一個一定尚未執行的位置。

Copy 成功時，目的範圍應依 descriptor 順序包含全部來源內容；失敗時則不能要求完全沒有修改。例如四筆來源中 0、1、3 已成功，但 2 未成功，DW0=2；它無法證明 3 完全沒執行，也無法證明 2 沒有任何部分寫入。若完全沒有寫入目的資料，DW0 必須為 0；反過來，DW0=0 並不能證明目的資料完全沒改變。

3. 判讀時要保留的條件

超過來源範圍或總長度限制使用 Command Size Limit Exceeded（1/83h）。Format0h／1h 的來源與目的重疊是 Host 應避免的情況，不能一律要求 Overlapping I/O Range；Formats2h／3h 則明定禁止相應重疊並回 1/87h。驗證 Status 前必須固定 descriptor format。

NVM 1.3 適用的 NVMCSA 規則，將 Copy 的目的寫入當成一個 Write 套用原子性要求，不表示任意大小的 Copy 都是整筆原子操作。失敗重試前，要查目的內容、原子子範圍與來源是否已被其他寫入者更動，不能只從 DW0 指定的位置繼續就宣告安全。

1. 機制與適用範圍

操作影響 NSID 指定的 LBA 範圍，不等於停用整個 namespace。共享該 namespace 的其他 controllers 也可能觀察到這個無效狀態，因此比對前要確認是否有其他 Host 改寫相同範圍。

SLBA 指起點，NLB 採 zero-based。教學假設 SLBA=200、NLB=1，目標是 200 及 201 兩個區塊；它不使用 Read／Write 的資料 buffer 來裝無效標記，而是由命令本身要求狀態改變。

2. 用操作與結果理解

確認 Write Uncorrectable 支援，以及 NVM Identify Controller 的 WUSL 與 ONCS.NVMWUSV。WUSL 非零時，NVMWUSV=1 表示建議最大大小；NVMWUSV=0 才依該值套用必須拒絕超限的規則。命令不傳 Host 資料，所以不能直接套 MDTS。

先對目標寫入已知合法資料並確認成功，再執行 Write Uncorrectable。等其成功後，單獨讀取標示範圍與一個未標示的對照範圍；最後以合法 Write 重新寫入目標，確認無效狀態被清除，而不是只做 Reset 期待它消失。

Write Uncorrectable 本身可以成功；隨後對標示區塊的 Read 應回 Unrecovered Read Error。重新寫入該區塊會清除無效狀態，之後在沒有其他錯誤的情況下，可以讀回新寫入資料。這三個結果一起才構成完整驗證。

3. 容易誤判的地方

後續 Read 的 Unrecovered Read Error 是 2/81h，不是標示命令必須回報失敗。WUSL 有效且 NVMWUSV=0 時，超過大小限制的標示命令須回 Invalid Field（0/02h）；NVMWUSV=1 的建議大小不能當成相同的強制拒絕條件。

將標示命令的成功、後續 Read 的錯誤及重寫後的結果，與當時 Error Information／SMART 一起保存。即使讀取錯誤被計入相應統計，也不能據此把已知由 Host 標示造成的錯誤，改解釋成硬體退化。