【SPDK 用户态存储】用户态存储全景：从 Reactor 到 NVMe-oF 的坐标系
内容提要
本文为SPDK用户态存储栈系列首篇，定位其相对内核NVMe与io_uring的生态位，提出五条坐标系（I/O路径、线程消息、设备独占、bdev、远端控制面）作为排障语言，并规划16篇阅读路线，强调用户态轮询栈的CPU税与运维代价。
延伸解读
五条坐标系的排障价值
本文提出的五条坐标系（I/O路径、线程消息、设备独占、bdev、远端控制面）为SPDK排障提供了结构化语言。例如，当CPU单核打满但IOPS上不去时，可优先检查线程与消息轴，而非直接怀疑固件；当提交成功但回调迟迟不来时，应聚焦I/O路径轴。这种归因方式缩短了排障路径，但要求读者先熟悉各轴含义，否则可能对不上号。
用户态栈的代价与适用边界
SPDK用户态栈以CPU轮询税和设备独占为代价，换取更可控的尾延迟和更短的归因路径。文章明确指出，在混部严重、负载波动大或核为租用等场景下，该设计可能成为成本中心。因此，架构师在决定采用前，需评估组织是否具备设备独占和专用轮询核的运维能力，否则机制再完善也难以落地。
与内核路径的对照：保证集变窄
与io_uring等内核路径相比，SPDK将完成模型的托底从内核驱动和块层语义，转变为用户态reactor是否运行、缓冲是否DMA安全、设备是否仍在VFIO上。这意味着保证集变窄，归因路径变短，但运维面更锋利。读者需理解这一本质差异，才能正确选择适用场景，避免在不适合的环境中强行使用用户态栈。
Q&A
SPDK 用户态存储栈相比内核 NVMe 和 io_uring 有什么不同？
SPDK 将驱动和块栈搬进用户态，采用 reactor/poller 轮询模型，设备独占，绕过内核，以获得更低的延迟和更确定的尾延迟；而内核 NVMe 和 io_uring 仍依赖内核驱动和块层，中断或异步完成通知，共享调度税较高。
SPDK 的 reactor 和 poller 是什么？为什么说在 reactor 上阻塞会饿死同核 poller？
Reactor 是 SPDK 每核的事件循环，poller 是注册到 reactor 上的轮询函数。由于 reactor 是单线程顺序执行，如果在某个 poller 中阻塞，就会导致同核上其他 poller 无法运行，从而饿死它们。
SPDK 如何实现设备独占？使用 scripts/setup.sh 会有什么影响？
SPDK 通过 scripts/setup.sh 分配大页并将 NVMe 设备从内核驱动解绑到 VFIO/UIO，实现设备独占。这带来用户态可见性，但代价是同机内核路径暂时不可用，其他进程无法访问该设备。
SPDK 中的 bdev 是什么？它和 Linux 块层有什么不同？
bdev 是 SPDK 的统一块设备抽象，提供读写和完成回调接口，后端可以是 NVMe、aio、内存盘等。相比 Linux 块层，bdev 砍掉了通用调度和大量内核语义，保留用户态队列和回调契约。
SPDK 如何支持 NVMe-oF？它和内核 initiator 如何对接？
SPDK 通过 NVMe-oF target 将远端命令落到本地 bdev，支持 RDMA 和 TCP 传输。与内核 initiator 对接时，需要遵循 NVMe-oF 规范，确保线缆另一端兼容。
SPDK 的 CPU 税和运维代价是什么？
SPDK 采用轮询模式，空闲时 CPU 占用高，且需要设备独占和专用轮询核，运维上需要专门的编制来管理，否则机制再漂亮也填不平编制缺口。
SPDK 排障时首先应该关注什么？
排障第一问是“停在哪条轴”，即先判断问题落在 I/O 路径、线程消息、设备独占、bdev 还是远端控制面，而不是一上来就怀疑固件或重跑 fio。
