Linux io_uring 固定文件热更新怎么做：draining 状态与 IORING_REGISTER_FILES_UPDATE 验收

io_uring 请求突然返回 EBADF 时，先别直接判定成“普通文件描述符被提前关闭”。只要 SQE 设置了 IOSQE_FIXED_FILE，sqe->fd 表示的就是固定文件表索引；索引指向空槽、注册表和业务资源表错位，或是更新时还有请求在使用旧索引，都会让错误表现得和常规文件生命周期异常很像。

先把真实 fd 和固定索引分开记录

普通 io_uring 请求会把 sqe->fd 解释为进程文件表里的真实描述符。注册文件后再设置 IOSQE_FIXED_FILE，同一个字段就变成了已注册数组的下标：真实 fd 可能是 7，但固定索引是 0。把 7 直接填进 SQE，内核会去查固定表的第 7 项，而不是回到进程文件表找 fd 7。

int files[] = {input_fd, output_fd};
int rc = io_uring_register_files(&ring, files, 2);
if (rc flags |= IOSQE_FIXED_FILE; /* 0 是固定索引，不是 input_fd */

日志里建议把两种编号放在独立字段中，至少保留 raw_fd、fixed_index、ring_generation 和文件角色。这样看到 EBADF 时，能第一时间判断是打开阶段的 fd 无效，还是请求阶段的固定索引没有对应资源。

注册返回成功，为什么请求仍会失败

IORING_REGISTER_FILES 成功只代表这一次注册动作通过，不代表业务后续使用的每个索引都一直有效。注册数组长度、传入 fd 是否已经关闭、调用方的 RLIMIT_NOFILE 限制，都应该和 ring 标识一起记录下来。

liburing 封装函数的返回值也不能省略。注册前关闭了数组中的 fd，或者注册数量和资源管理器记录不一致时，后续的请求错误往往只剩一个笼统的 EBADF，没有这几组上下文根本没法复盘。

稀疏表的空槽不能直接提交

需要动态替换文件时，可以先创建稀疏固定表。空槽由 -1 表示，含义是“这里暂时没有文件”，不是可以交给读写请求的特殊文件描述符。提交前如果只检查索引范围、不检查槽位状态，就会得到稳定复现的 EBADF。

int rc = io_uring_register_files_sparse(&ring, 4);
if (rc 

更新成功后还要确认业务侧的索引状态已经变为 ready。不要用“更新函数返回非负”替代资源状态机；更新结果、索引号和文件角色应该一起写入可检索日志。

在线替换时，如何避免旧请求和新文件交错

IORING_REGISTER_FILES_UPDATE 可以把稀疏槽填入新文件、移除旧文件，或原位替换已有文件。但它处理的只是注册表更新，不会替业务自动完成请求切换。一套稳妥的切换顺序是：先停止把新请求分配到目标索引，等待已经使用该索引的请求全部完成，再执行更新，确认新 fd 可用后发布新的注册批次。

1. 资源管理器把目标索引标为 draining，拒绝新的分配请求。
2. 等待该索引关联的 SQE 全部收到 CQE，记录未完成数量为零。
3. 打开新文件并执行 io_uring_register_files_update()。
4. 验证更新返回值和新文件身份，再把索引标为 ready。

如果业务必须允许并行更新，就至少给每次请求带上注册批次。收到 CQE 时核对批次和固定索引，避免把旧文件请求的结果归到新文件上。内核可能在仍有请求使用资源时延后释放旧引用，因此“更新调用返回”和“所有旧请求都已完成”是两个完全不同的观测点。

把 EBADF 排查收敛成一张检查表

• 确认标志：SQE 是否真的设置了 IOSQE_FIXED_FILE，以及调用路径是否混用了普通 fd。
• 确认索引：固定索引是否小于注册表长度，目标槽位是否为空，业务资源表是否发生过重排。
• 确认资源：原始 fd 是否在注册前有效，文件是否被错误关闭，注册批次是否与请求一致。
• 确认更新：更新返回值是否符合预期，旧请求是否已经完成，新状态是否真正发布。
• 确认限制：注册数量和进程的 RLIMIT_NOFILE 是否匹配，目标内核与 liburing 版本是否支持所用接口。

常见问题

IOSQE_FIXED_FILE 下 fd 应该填什么？

填已注册文件表中的索引，不是进程文件表里的原始 fd。索引 0 是否对应原始 fd 7，要看注册数组的实际顺序。

稀疏固定文件表里的 -1 能提交吗？

不能。-1 表示空槽，必须先用文件更新接口填入有效 fd，再提交使用该索引的请求。

更新固定文件后可以立刻关闭新 fd 吗？

注册表会持有内核文件引用，但业务仍应按资源生命周期管理原始 fd，通过请求完成和注册批次日志确认关闭时机，不能用一次成功返回推断所有并发请求都已完成切换。

为什么只打印 EBADF 不够？

因为它可能来自普通 fd 无效、固定索引越界、空槽提交或资源切换竞态。至少同时打印原始 fd、固定索引、注册批次、更新结果和 CQE 结果，才能定位具体分支。

固定文件的收益来自减少每次请求的文件引用管理开销，但前提是编号模型清晰、空槽状态可见、在线更新有明确的切换边界。把真实 fd、固定索引和注册批次拆开记录，再用 draining 到 ready 的状态机管理替换，通常比围绕一个 EBADF 反复重试更快找到根因。