題幹與適用場景
請設計一個把虛擬區塊裝置邏輯放在使用者態的系統：核心向應用程式暴露區塊裝置，使用者態服務負責 loop、遠端區塊儲存或 qcow2 映射。系統要求高並發 I/O、使用者態程序崩潰恢復、權限隔離與可觀測性。
Linux ublk 文件把這類框架拆成控制面與資料面：/dev/ublk-control 管理裝置，/dev/ublkb* 承載區塊 I/O，使用者態服務透過 io_uring passthrough 取得請求並提交結果。面試重點是請求生命週期、故障語義與安全邊界，不是簡單把檔案讀寫搬到程序裡。
面試官考察點
面試官會看你能否畫出控制面、核心區塊層、io_uring 與使用者態後端的邊界；能否解釋 queue、tag、buffer 與 completion 的一一對應；能否在 per-I/O 與 batch 模式間取捨；能否定義 server 崩潰時 requeue、fail 或重發語義；能否處理零拷貝、特權、容器隔離與指標。
回答前需要釐清的問題
負載與後端
確認讀寫比例、I/O 大小、佇列數、延遲目標、後端是本地檔案、遠端 NBD 還是寫時複製格式，以及是否要求順序一致性。
故障與資料安全
確認使用者態服務崩潰、網路分區、後端短寫、重複寫與裝置卸載時的語義；確認是否能接受重發導致的 double-write 風險。
權限與部署
確認誰能建立裝置、誰能讀取 /dev/ublkc*、是否允許在容器內執行、是否允許 zero-copy 所需特權，以及裝置租戶之間如何隔離。
30 秒回答框架
「我會把控制面和資料面分開：控制面協商佇列、深度與特性後啟動裝置，資料面按 queue/tag 從 io_uring 取得請求並提交結果。每個請求都有明確 owner、狀態與逾時；使用者態服務退出時先凍結裝置，再按策略 requeue、fail 或允許重發。預設使用拷貝路徑，只有可信且具備權限的後端才啟用 zero-copy。指標涵蓋佇列深度、完成延遲、重試、丟棄與恢復時間，並以一致性測試驗證卸載與恢復。」
分步驟深入解答
第一步：劃分控制面
控制面提供新增、設定/讀取參數、啟動、停止與刪除裝置的命令。新增時協商 nrhwqueues、queue_depth 和最大 I/O 緩衝區；參數在啟動前凍結，啟動後才暴露 /dev/ublkb*。裝置編號與後端特定資訊由使用者態保存。
第二步：設計資料面請求
區塊層為每個佇列分配唯一 tag，使用者態服務按 (queue, tag) 關聯請求。固定映射區描述 offset、length、操作與 flags；服務透過 io_uring passthrough 取得通知，再把結果與完成位元組數提交回核心。
第三步：選擇 per-I/O 或 batch
傳統 per-I/O 命令容易理解，每個 tag 由一個 daemon 負責；batch 模式按佇列批次準備與提交，減少系統呼叫並允許工作動態分擔。遷移時不能同時混用兩套命令，必須用壓測比較尾延遲、CPU 與負載平衡。
第四步：定義恢復狀態機
裝置狀態可以是 running、quiescing、recovering、failed。服務退出時停止向使用者態派發新 I/O，等待或標記在途請求，再執行 STARTUSERRECOVERY。REISSUE 適合能容忍重複寫的後端；FAIL_IO 將在途與後續請求明確失敗，避免偽造成功。
on_server_exit:
quiesce_device()
if policy == REISSUE:
requeue_inflight()
else:
fail_inflight_and_future_io()
wait_new_server_ready()
end_user_recovery()第五步：處理緩衝區與零拷貝
普通路徑使用使用者態預先分配的緩衝區並由核心複製，邊界簡單。zero-copy 需要註冊固定 buffer、對齊後端 segment，並由可信服務正確填充 READ 資料與返回位元組數；錯誤可能把未初始化核心緩衝區暴露給客戶端，因此要限制權限並審計生命週期。
第六步：建立權限與容器隔離
特權控制命令和裝置存取分離。啟用 unprivileged device 時，核心仍需驗證呼叫者擁有的 char device；容器內只暴露對應裝置節點。使用者態後端不應直接取得超出目標裝置的檔案、網路或 KMS 權限。
第七步：驗證效能與正確性
用 fio 或真實工作負載測量 IOPS、p50/p99 延遲、佇列深度、CPU、複製位元組與恢復時間。注入服務崩潰、後端逾時、短寫、裝置刪除與重複提交，檢查每個請求只完成一次或按策略明確失敗。零拷貝與拷貝模式分別驗證資料校驗和越界。
高品質示範回答
我會將 ublk 類系統拆成控制面、核心區塊層、io_uring 資料面與使用者態後端。控制面在啟動前協商佇列和緩衝區，資料面用 (queue, tag) 追蹤請求，完成時校驗狀態與位元組數。服務崩潰觸發 quiesce 和恢復狀態機：可重放後端選擇 reissue，不能承受重複寫的後端選擇 fail。預設拷貝，zero-copy 只給可信、對齊且有權限的服務。上線前做尾延遲、故障注入、權限隔離與卸載一致性測試。
常見錯誤
- 錯誤表現： 讓使用者態服務直接關閉裝置檔案。→ 失敗原因： 在途請求與核心佇列狀態未定義。→ 修正方法： 先停止派發、凍結裝置，再按恢復策略處理請求。
- 錯誤表現： 所有後端預設 zero-copy。→ 失敗原因： 緩衝區生命週期、特權與未初始化資料風險更大。→ 修正方法： 預設拷貝，按 capability 與審計結果開啟。
- 錯誤表現： 用全域鎖保護所有佇列。→ 失敗原因： 多佇列並發被串行化。→ 修正方法： 按 queue/tag 分片狀態，單獨測量鎖競爭。
- 錯誤表現： 只測正常 I/O 吞吐。→ 失敗原因： 服務退出、短寫與重複寫決定資料一致性。→ 修正方法： 將恢復狀態機和故障注入納入驗收。
追問及應對
什麼時候選擇 batch I/O？
當系統呼叫和通知成本明顯、佇列有足夠並發且工作可以動態分擔時選擇 batch。若後端需要精細 per-I/O 所有權或低並發，傳統模式更易除錯。
REISSUE 如何避免資料損壞？
只對冪等或可偵測重複寫的後端啟用，並用請求 ID、寫入版本或日誌去重；無法證明冪等時選擇 fail 並讓上層恢復。
如何限制 zero-copy 的安全影響？
將 buffer 註冊、取消註冊和裝置權限綁定到同一可信服務，校驗地址、長度、對齊與完成位元組數，禁止跨租戶共享可寫映射。
裝置刪除時如何保證一致性？
先停止新請求，等待已提交請求完成或失敗，確認使用者態佇列為空，再釋放裝置節點與映射區；將逾時請求記錄為可追蹤失敗，而不是靜默丟棄。