Linux io_uring registered files怎样减少高频 I/O 的文件描述符开销

Linux io_uring 的 registered files（也称 fixed files）适合一组已经打开、会被反复用于 I/O 的文件：先把它们注册到当前 ring 的文件表，后续请求用槽位索引配合 IOSQE_FIXED_FILE 引用文件，从而减少每次请求的普通文件描述符查找和文件引用管理开销。注册本身有成本，还要维护槽位，所以不能把它理解成所有 I/O 都值得开启的加速开关。

liburing 官方地址：https://github.com/axboe/liburing

先看文件是否会被反复使用

考虑一个分片读取服务：进程启动后打开一组数据文件，多个工作线程不断读取其中的小块。文件集稳定、每个文件承接很多请求时，一次注册的成本可以由后续请求分摊。这类工作负载值得比较 fixed files 与普通 fd 的 CPU 成本。

另一种服务每次请求都打开一个临时文件，读一次就关闭。若再为每个文件注册、更新和释放槽位，新增管理成本可能抵消收益。面对这种情况，先保留普通 fd 路径，通常更容易维护。

选型时先记录三个量：每个文件平均复用次数、文件集更换频率、I/O 请求在 CPU 上的成本。设备等待时间占主导时，减少少量文件引用开销也未必明显改变端到端延迟。这里讨论优化机制，不提供未经测量的提速比例。

普通fd与固定槽位到底差在哪里

普通请求把进程文件描述符放进 SQE 的 fd 字段；内核需要找到对应文件并管理请求使用的引用。文件表在线程间共享时，这类引用管理成本尤其值得关注。注册文件则让 ring 持有相应文件引用，后续请求通过该 ring 的注册表访问它们。

假设数组 files[0] 保存普通 fd 42。注册成功后，固定文件请求传的是槽位 0，而不是 42。数字 0 并不因此成为整个进程通用的文件句柄，它只在指定 ring 的注册表语境中有意义。

决定解释方式的是 IOSQE_FIXED_FILE：设置它，sqe->fd 表示注册索引；不设置，则表示普通 fd。漏掉标志不一定立即报错——如果那个数字刚好也是一个有效普通 fd，请求可能指向另一个文件。因此最好用不同变量名区分 os_fd 与 slot。

把注册和读取准备拆成两个明确动作

下面用两个 C 函数展示核心接口，不包含完整事件循环。调用方已经初始化 ring、成功打开只读文件，并负责 SQE 提交、完成回收及缓冲区生命周期。示例只读取明确偏移处的一块数据，不涉及 O_DIRECT 的对齐要求或注册缓冲区。

#include 
#include 

/* 初始化阶段注册一个文件：成功后注册表槽位为0。
 * 此函数要求ring尚未注册文件表；返回值沿用liburing的负错误码。 */
static int register_input(struct io_uring *ring, int os_fd)
{
    int files[1] = { os_fd };
    return io_uring_register_files(ring, files, 1);
}

/* 只准备一次读取，buf由调用方持有到该请求完成。
 * fixed为真时，target必须是本ring的槽位；否则它是普通fd。 */
static int prepare_read(struct io_uring *ring, int target, int fixed,
                        void *buf, unsigned len, unsigned long long offset,
                        unsigned long long request_id)
{
    struct io_uring_sqe *sqe = io_uring_get_sqe(ring);
    if (!sqe)
        return -EAGAIN;  /* 无空闲SQE：由事件循环提交或回收后再安排 */

    io_uring_prep_read(sqe, target, buf, len, offset);
    if (fixed)
        sqe->flags |= IOSQE_FIXED_FILE;
    io_uring_sqe_set_data64(sqe, request_id); /* 将完成事件关联到请求对象 */
    return 0;
}

注册成功的返回值是 0；失败返回负错误码。只有成功后，才调用 prepare_read(ring, 0, 1, ...) 使用槽位 0。普通路径则调用 prepare_read(ring, os_fd, 0, ...)。这里的省略号表示函数的其余参数，便于对照参数语义，并非可直接编译的完整调用。

准备返回 0 只说明已经取得并填好 SQE，不代表提交成功，更不代表读取成功。调用方还要检查提交接口的返回值；回收 CQE 时，res 是负错误码，res == 0 表示读到文件末尾，正数表示实际读入字节数。短读需要按业务决定是否继续安排剩余部分。

示例显式传入文件偏移，避免并发读取争用共享当前位置。缓冲区也不能在函数返回后立刻复用：它属于请求对象，要保留到该请求的完成事件被处理。固定文件仅改变文件引用方式，不改变这些异步 I/O 规则。

槽位更新和资源释放要有同一个负责人

普通 fd 与注册引用分别有生命周期。注册成功后，ring 自己持有文件引用，因此可以按应用设计关闭原始普通 fd；但 close(os_fd) 不会顺带删除注册槽位。反过来，解除注册也不等于替你关闭仍然保留的普通 fd。

应用需要给每个槽位维护文件身份和使用状态。更换文件时，先停止把新请求分配到旧映射，处理仍未提交的 SQE，并按照应用的完成计数等待相关请求结束，然后再替换映射。这样的保守管理办法便于推理；不要把“索引相同”当成“始终还是同一个文件”。

io_uring_register_files_update 可以更新已注册表中的一个或多个槽位，成功返回更新的文件数，而不是统一返回 0。将条目设为 -1 可以清空槽位，空槽位不能拿来执行固定文件 I/O。如果要预建空表再填充，可研究 sparse 注册；官方文档注明该变体需要 Linux 5.19 及以后内核，部署时还须匹配实际 liburing 能力。

退出时先停止产生请求并妥善结束在途 I/O，再处理注册资源。io_uring_unregister_files 可以显式解除整张表，销毁 ring 也会释放其注册文件资源。不要在“已经调用释放函数”这一点上推导业务请求已全部成功；完成状态仍应从请求自己的 CQE 获取。

怎样比较收益，以及哪些场景先别用

比较时只切换普通 fd 与 fixed files，保持文件、读取范围、块大小、队列深度、线程模型和缓存条件一致。把注册或更新成本单独记录，同时计入服务整体成本，避免只测稳定期而遗漏高频换文件的代价。

建议观察每完成一次 I/O 消耗的 CPU 时间、吞吐量以及尾延迟，并记录文件复用次数。吞吐量未提高但单位请求 CPU 成本降低，可能仍有价值；相反，如果槽位锁争用、管理逻辑或存储延迟掩盖了收益，就不能仅凭用了注册接口宣称优化成功。

对大量短命文件、频繁切换文件集、请求量很小的程序，先采用普通 fd。对于多个 ring，槽位归属必须单独维护，不能把一个 ring 的索引直接交给另一个 ring。registered files 也不等于 registered buffers：前者针对文件引用，后者针对内存缓冲区，开启其中一个不会自动获得另一个的效果。

按文件生命周期作最终选择

注册后还能提交普通fd请求吗？

可以。同一个 ring 可以同时使用两条路径；每个 SQE 都必须给出与标志匹配的目标数字。

注册文件会自动变成零拷贝吗？

不会。它优化的是文件引用管理；数据是否复制、是否使用页缓存、读取多大范围，仍由所用操作和文件条件决定。

为什么设置了标志仍然失败？

先看该 CQE 的负错误码，再检查槽位是否属于当前 ring、是否已经成功注册、是否为空，以及所用操作的参数限制。不要把所有错误都归因于 registered files。

接口参考：https://github.com/axboe/liburing/blob/master/man/io_uring_registered_files.7；https://github.com/axboe/liburing/blob/master/man/io_uring_register_files.3；https://github.com/axboe/liburing/blob/master/man/io_uring_prep_read.3。