【SPDK 用户态存储】选型收束：机制排除树与系列开放问题

前 15 篇把 SPDK 钉成可排障的用户态存储栈：reactor、绑盘、NVMe、bdev、NVMe-oF、vhost、RPC、观测与对照。选型若再写成「各有优劣看场景」，等于把机制丢掉。

本文是终章：用机制排除树收束相对内核 NVMe / O_DIRECT+io_uring 的位置，回收阅读路径，并列出仍开放的问题。不做跨方案延迟排行榜；官方 Performance Reports 只作外部方法参考（第 13 篇）。

本文是「SPDK / 用户态存储栈」系列第 16 篇（共 16 篇 · 终章）。→ 系列目录

篇目	核心内容
第 15 篇 · 对照内核路径	共置与迁移税
第 16 篇 · 选型收束	排除树、阅读回收、开放问题

版本锚定：机制结论对齐 SPDK v26.01（LTS）。与 storage/03、storage/79、io_uring、distributed/38 分工：那些文负责协议、内核组合路径或分布式 RADOS；本文负责「用户态轮询栈能力是否必要」。

一、先排除，再选择

flowchart TD
  need{"Need userspace poll stack<br/>or NVMe-oF/vhost target?"}
  need -->|"no"| kpath{"Need app-managed cache<br/>+ high IOPS submit?"}
  kpath -->|"yes"| uring["O_DIRECT + io_uring"]
  kpath -->|"no"| knvme["Kernel NVMe / block"]
  need -->|"yes"| cpu{"Can pay dedicated<br/>poller cores + VFIO?"}
  cpu -->|"no"| rethink["Stay kernel path<br/>or cloud block"]
  cpu -->|"yes"| role{"Primary role?"}
  role -->|"local userspace block"| local["SPDK bdev / app"]
  role -->|"fabric target"| nvmf["SPDK NVMe-oF"]
  role -->|"VM block backend"| vhost["SPDK vhost"]

SPDK 不是默认赢家：它赢在「用户态轮询存储数据面 + 可 RPC 编排的 target/vhost」成为一等公民之时；它输在组织只要标准块设备、付不起核税、或没有配置生命周期纪律之时。

排除树要诚实对待沉没成本：故障手册与监控全挂在 nvme-cli/块层上时，仅因「官方 report 很好看」就迁移，通常付不起第 15 篇的迁移税。反向亦然——已在 SPDK 上跑 nvmf/vhost 的团队，不必为「回到内核更简单」三字拆掉可排障坐标，除非独占与核税已成为硬约束。

二、机制差（非跑分）

补充判决：

• 选 内核 NVMe：通用 OS 存储、共置、生态工具优先。
• 选 O_DIRECT+io_uring：应用已决定绕过 Page Cache，并要降 syscall（79）。
• 选 SPDK：用户态目标端、与轮询运行时绑定的数据面、或明确要绕过主机内核块层的栈。

混合不犯规：系统盘内核、少数盘 SPDK target、应用盘 Direct+uring。代价是多套排障坐标——第 14 篇清单要写明先进哪一层。

三、系列阅读路径回收

五个关键问题（系列 index）到终章仍然够用：争议要么落在「要不要付轮询核税与独占」，要么落在「配置面是否有库存与门禁」，很少落在营销形容词上。

若时间只够一篇：读 01 全景 建缺口意识，再读本篇排除树，然后按主业跳进 08/11/14 之一。跳读风险是把官方 Performance Report 当成对本机的承诺，或把 RPC 热改当成已持久化。

写给后续维护者：升到下一 LTS（如 27.01）或改绑盘/传输默认时，先重跑第 14 篇与 iostat 相关门禁，再更新本篇排除树假设。非 LTS（如 26.05+）特性须显式标注，默认不进基线。

四、系列级开放问题

下列问题有工程与社区争议；本系列给了机制语言，但不假装已关闭。不用延迟排行榜代替回答。

4.1 ZNS / KV 命令集在 bdev 上的暴露

分区命名空间与键值命令集如何在统一 bdev 接口上暴露，而不把「块设备假设」偷偷砸盘？应用是直接认 ZNS 语义，还是继续伪装成传统块？（入口：第 6–7 篇；NVMe ZNS 背景见 storage/03；SPDK 模块与文档中的 ZNS/KV 相关接口随版本演进，核对 v26.01 实际 RPC。）

可检验子问题：在给定 SPDK 版本下，ZNS 特有失败能否被现有 bdev_get_iostat 错误维区分，还是必须协议专用计数？

4.2 DPU / 智能网卡卸载后，主机侧还剩什么

当 NVMe-oF 或存储数据面卸到 DPU（storage/73、storage/70）后，主机进程还是否需要完整 SPDK reactor？控制面与观测信号如何跨主机/DPU 对齐？

可检验子问题：一次超时是主机 RPC 配置错误、DPU 侧传输问题，还是介质问题——现有五轴是否要扩成「六轴（卸载域）」？

4.3 与 Ceph OSD 用户态栈的关系（边界）

Ceph 的 RADOS/OSD 有自己的用户态 I/O 与蓝店（BlueStore）路径；社区亦存在将高速路径与 SPDK 类组件结合的讨论与工程变体。本系列不把 Ceph 收进 SPDK 排除树的下一叶——那是分布式存储内核问题。

边界外链：distributed/38 讲 CRUSH/RADOS 工程实现。开放问题只保留一句可检验的：若 OSD 数据面采用用户态 NVMe 轮询，故障域与 Ceph 恢复/回填线程的 CPU 隔离如何声明？ 答案不在本系列 16 篇内关闭。

4.4 轮询核税 vs 尾延迟 SLO

专用核空转税在何种利用率与尾延迟目标下可接受？与 io_uring 完成通知模型如何在同一 SLO 框架里比较才不偷换口径？（入口：第 2、13、15 篇；官方 Performance Reports 的硬件与方法章节。）

4.5 多路径与故障切换可观测性

路径级 iostat 与聚合统计并存时，告警如何避免「半死路径」误判？failback 后直方图形状变化是否有稳定信号？（入口：第 13–14 篇。）

这些问题要求后续事故复盘或专文带着排除树与五轴回去量：量的是核占用分布、RPC 配置漂移、路径错误码、DPU 往返——而不是再写一张无口径延迟榜。

4.6 配置面经济学与「假 xDS」

SPDK JSON-RPC 没有内建的大规模推送与依赖 warming 模型（对照站内 Envoy 系列的 xDS 讨论）。当节点数上升，自建编排若只是「对每台 ssh rpc.py」，会在部分成功、版本分叉与回滚上重复发明控制面。开放问题是：何时值得做声明式库存 + 对账，何时应承认「单机/少量目标端」才是 SPDK 甜区？

可检验子问题：一次滚动升级中，有无工具能回答「哪些节点的 nvmf listener 集合与库存 hash 不一致」——若不能，排除树上「编制」一叶就应判负。

终章立场可以收成一句：SPDK 值得写 16 篇，是因为它把用户态轮询存储的失败变成可命名的机制；选型与开放问题若离开这些名字，讨论会退回品牌口号。

给读完本系列的人三条可执行收束：

1. 用排除树写一句「我们选/不选 SPDK 的机制理由」，贴进架构决策记录。
2. 若选了，把第 14 篇清单与第 12 篇库存纪律写进发布门禁，并指定 reset iostat 的权限。
3. 若没选，把对照表留给下一次硬件代际复盘——不要每年用无口径跑分重开争论。

排除树用完之后，建议把结果写成三种档案之一，避免口头传说：

1. 不采用 SPDK：写明卡在哪一叶（核税、独占、编制、云盘不可直通等），以及复盘触发条件（例如换代 NVMe、出现明确 target 产品需求）。
2. 采用但限域：写明只用于 nvmf/vhost/某几块盘，共置规则与五轴门禁负责人。
3. 采用并作为主存储数据面：写明库存工具、升级 LTS 策略、与官方 report 的引用纪律。

三种档案都可以在硬件或编制变化时重跑排除树；重跑时禁止只贴新的跑分截图。终章列出的开放问题（ZNS/KV、DPU、Ceph 边界、核税、多路径、配置面经济学）适合作为年度技术复盘议题，而不是要求本系列在当下给出假关闭。

与站内相邻系列的接法也一并收回：协议与接口演进读 storage/03；本机 Direct+uring 读 storage/79 与 io_uring；云块与新硬件读 70/73；分布式 RADOS 读 distributed/38。本系列补的是用户态轮询存储栈坐标，不替代其中任何一篇。若读者只记住一个动作，记住这个：先排除，再实验，再迁移——实验必须自带口径四元组，迁移必须自带回滚与库存。

最后回到五个关键问题（系列 index）：延迟与失败落点、独占运维代价、bdev 相对内核块层的取舍、NVMe-oF 映射与传输模式、以及何时不该离开内核路径。终章没有发明第六个营销问题。若讨论开始出现「生态更火」「简历更好看」之类理由，应把它标成非机制输入，并在决策记录里降权。

维护提示：正文版本钉在 v26.01；当官方发布下一 LTS 时，优先更新环境、传输与 RPC 状态机相关章节，再改本篇排除树假设。非 LTS 特性继续保持「显式标注才写入」的纪律，防止系列被短生命周期开关拖离可运维基线。

若你的组织同时运行 Envoy/HAProxy 类数据面系列中的排除树文化，可以直接复用「先排除、再实验、不贴无口径榜」的纪律；换的只是轴名与证据对象，不是决策伦理。

开放问题跟踪不必开新系列也能开始：每个问题指定一名负责人与「下一次可检验实验」的一句话定义，季度回顾是否仍开放。关闭条件必须是机制证据，而不是投票或厂商幻灯片。

五、参考资料

规范 / 官方文档（A）

• spdk.io/doc；Releases / v26.01；Performance Reports（外部、硬件绑定）。
• 本系列引用过的 Event Framework、NVMe Driver、Block Device、NVMe-oF、vhost、JSON-RPC、App Overview。

站内边界

• storage/03、79、io_uring、storage/70、73、distributed/38。

核心论文 / 谱系入口（研究）

• NVMe / NVMe-oF 规范族（协议定义；非本系列重写对象）。
• 用户态轮询 I/O 与存储软硬件协同：以 SPDK 设计文档与后续系统会议工作为线索；具体 paper 选型随专题文展开，终章不堆未读摘要。

→ 上一篇：对照内核路径 · 系列目录