题干与适用场景
请设计一个把虚拟块设备逻辑放在用户态的系统：内核向应用暴露块设备，用户态服务负责 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 注册、取消注册和设备访问绑定到同一可信服务与设备权限，校验地址、长度、对齐和完成字节数，禁止跨租户共享可写映射。
设备删除时如何保证一致性？
先停止新请求，等待已提交请求完成或失败，确认用户态队列为空，再释放设备节点和映射区；将超时请求记录为可追踪的失败，而不是静默丢弃。