我最开始想确认的是一个很具体的问题：Mooncake Classic TE 和 TENT 打开的究竟都是文件系统普通文件，还是也能把 /dev/nvme0n1 这样的 SSD 裸块设备交给 GDS？源码里两边都会调用 open(path, O_DIRECT)，NVIDIA cuFile 又确实接受 device fd，看起来答案应该是“可以”。继续向上追到 Segment 层后，结论却发生了分叉。

这篇文章把这条调用链从头串起来：先解释普通文件、块设备、S_ISREG 与 S_ISBLK，再看 GDS 提供了什么 API、Mooncake 实际用了什么，最后落到 cuFileBatchIOSubmit 的同一组参数为什么在两个场景里具有不同含义。核心判断是：GDS 统一了 I/O 接口，却没有替 Mooncake 补上块设备的容量、对齐、越界和独占语义。

在分析 Mooncake 的 NDS 接入位置时，经典 NVMeoFTransport 很容易被误认为 TENT GdsTransport 的前一版：二者都注册 buffer 和文件 handle，都使用 cuFile Batch API，也都维护异步完成事件。

但这条旧路径真正特殊的地方不在 cuFile，而在 Batch 所有权。可运行的调用必须直接持有 Transport*，并始终走 xport->allocateBatchID → xport->submitTransfer → xport->getTransferStatus → xport->freeBatchID。一旦换成 engine->allocateBatchID → engine->submitTransfer，批次便由 MultiTransport 创建，NVMeoFTransport 无法附加私有 descriptor，最终返回 NotImplemented。

本文把这条旧路径单独展开：先给出从 NVMe-oF 挂载到专用测试的 SOP，再画出可运行路径与断路分支，最后按执行顺序逐句解释 Batch 分配、请求切片、cuFile 提交、完成事件聚合与资源回收。

上一篇文章把 TENT 的请求路径压缩成了一串箭头。那串箭头没有错，但它隐藏了代码走读时最容易断掉的几处连接：公共 Request 在哪里变成 TaskInfo，为什么 selector 会返回 GDS，一个逻辑 task 怎样展开成多个 cuFile slice，以及完成事件怎样重新聚合成公共状态。

本文固定在 Mooncake 提交 89da2c3a，只追踪一次成功的 GDS 读取。每个关键节点都给出实际会执行的 C++ 片段；代码语句保持原样，只增加中文走读注释和明确的省略标记。

一开始我只知道一件事：Mooncake 通过 TENT 接入了 NVIDIA GPUDirect Storage。真正沿代码往下追时，三个问题很快连在了一起：TENT 到底怎样调度一次传输，GDS 向上提供了哪些能力，以及新后端怎样实现同一套契约。

最关键的判断是：TENT 不是 GDS 的一层薄封装，而是负责 Segment、内存注册、后端选择、批次和状态推进的统一运行时；GdsTransport 才负责把 File Segment 请求翻译成 cuFile Batch I/O。 理清这条分工后，submitTransferTasks、cuFileBatchIOGetStatus 和新后端接口会自然落在同一张图里。