第 7 章 文件描述符、VFS 与 I/O 多路复用

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19

一个 fd 索引被三层结构逐级翻译的过程

  进程 A files_struct        系统级（与任何进程无关）
  ┌────────────────┐ ┌────────────────────────────────────┐
  │ 0 ─────────────┼▶│ struct file #1                     │
  │ 1 ─────────────┼┐│ f_pos=100  f_flags=O_RDWR|O_APPEND │
  │ 2 ─────────────┼┼▶│ f_count=2  ← 引用计数             │
  │ 3 ─────────────┼┼┐│ f_inode ───────────┐            │
  └────────────────┘││└────────────────────┼────────────┘
  进程 B（fork/dup）││ ┌────────────────────┼────────────┐
  ┌────────────────┐│└▶│ struct file #2     │            │
  │ 0 ─────────────┼┘  │ f_pos=0 ← 独立偏移 │            │
  │ 3 ─────────────┼──▶│ f_count=1          │            │
  └────────────────┘   └────────────────────┼────────────┘
                       ↑ 父子 fd 3 指向同一个 file
                                             ▼
   系统级 inode 表（唯一）：i_ino=131074 i_size=4096 i_nlink=1
   i_mapping ─▶ page cache（文件页）   i_sb ─▶ superblock
  ★ 关键：f_pos 在 struct file 里，不在 inode 里。谁共享 file，谁就共享偏移。

1
2
3
4
5

int fd1 = open("log.txt", O_RDWR);   // 生成 file#1，f_pos = 0
int fd2 = open("log.txt", O_RDWR);   // 生成 file#2，f_pos = 0，与 fd1 无关
read(fd1, buf, 10);                  // 只有 file#1.f_pos → 10
read(fd2, buf, 10);                  // 读到的仍是文件开头 10 字节
dup(fd1);   // dup 不新建 file，只把同一指针写入 fd 表另一槽位，f_count 加一

1
2
3
4
5
6
7

fork：子进程复制父进程整个 fd 表（数组内容是指针），所有 struct file 的 f_count 加一
"父写子读会串位"的因果链
  父 fork  ──▶ 父子 fd 表同址 → 同一个 struct file → 同一个 f_pos
  父 write(fd,"AAA",3)  ⟹  f_pos: 0 → 3
  子 read(fd,buf,3)     ⟹  从 f_pos = 3 读！拿到的是文件第 4~6 字节
  ★ f_pos 不是"每个进程各自的读写位置"，而是"每个 struct file 的位置"。
    这就是"父子进程各写一半日志会互相覆盖半行"的根因。

1
2
3
4
5
6
7
8
9

ulimit -n                 # 软限制（bash 默认 1024）；ulimit -Hn 看硬限制
ulimit -n 65535           # 为什么先调高：泄漏在 1024 时几分钟就撞墙，调高后
                          # 才能把"上限低导致的偶发失败"与"真正的泄漏"区分开
cat /proc/sys/fs/file-nr  # 系统级：已分配 / 未使用 / fs.file-max 上限
ls /proc/12345/fd | wc -l # 当前 fd 数量：泄漏排查第一步永远是"有多少、涨不涨"
ls -l /proc/12345/fd      # 指向 socket / 普通文件 / 管道 / anon_inode
cat /proc/12345/fdinfo/7  # pos、flags、mnt_id —— pos 就是 f_pos
lsof -p 12345 -n | awk '{print $5}' | sort | uniq -c | sort -rn
                          # 为什么加 -n：海量连接下 DNS 反解会让 lsof 卡住几十秒

1
2
3
4
5
6
7
8
9

硬链接：两个目录项指向同一个 inode
  /data/a.txt ──┐                ★ 没有"谁是原件"；删掉任一名字只是 i_nlink 减一，
                ├──▶ #131074        减到 0 才释放数据（引用计数式生命周期）
  /data/b.txt ──┘
软链接：独立文件，内容是"目标路径字符串"
  /data/link.txt ──▶ 自身 #131080，数据 = "/data/a.txt"（12 字节）
                       └─ 解析时读出字符串、再走一次路径解析 ──▶ #131074
  ★ 目标可不存在（悬垂）；可跨文件系统、可指向目录；解析深度上限 40 次嵌套。
  ★ 跨文件系统与指向目录这两条，恰好就是硬链接做不到的两条 —— 见 7.3 节表格。

1
2
3
4
5

fd_set rfds;                 // 位图，每一位对应一个 fd 号
FD_ZERO(&rfds); FD_SET(sockfd, &rfds);
int n = select(sockfd + 1, &rfds, NULL, NULL, &tv);
// poll 的改进：struct pollfd pfds[2]; pfds[0]={sockfd,POLLIN,0};
// poll(pfds, 2, timeout_ms) —— 数组替代位图，去掉 1024 上限，events/revents 分离

1
2
3
4

int epfd = epoll_create1(0);                     // ① 创建 eventpoll 对象
struct epoll_event ev = { .events = EPOLLIN, .data.fd = sockfd };
epoll_ctl(epfd, EPOLL_CTL_ADD, sockfd, &ev);     // ② 注册一次，此后不再重复传
int n = epoll_wait(epfd, events, MAXEV, -1);     // ③ 只取"就绪的那几个"

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22

epoll 的三块数据结构与回调路径（这才是 epoll_wait 为 O(k) 的根因）

  epoll_create1 → struct eventpoll
    rbr（红黑树）: 节点 = epitem{fd, event, 回调入口}
       (10)  键 (fd, struct file*) 有序，插入/删除 O(log n)
      /    \   ★ 服务于 epoll_ctl 的快速定位与去重
    (7)    (15)
    / \    /  \
  (3)(9)(12)(18)
  epoll_ctl(ADD) 额外做一件事：把 ep_poll_callback 注册到该 fd 对应文件的
    等待队列上（socket 即 sk_wq）—— 从此内核不再轮询，而是"数据到达时回调"。

  epoll_ctl → rdllist（就绪链表，双向）: ep9 ⇄ ep18 ⇄ ep3 → NULL
    ★ 只挂"已就绪"的 epitem，epoll_wait 直接摘取
  epoll_wait → wq（等待队列）: 链表为空时，调用线程挂此睡眠

  ①网卡收包→硬中断→软中断(NAPI)→协议栈，见第 9 章 9.1 节
  ②数据入 socket 接收队列，socket 变"就绪"  ③协议栈调 sk_data_ready()
  ④该 socket 等待队列上的回调被逐个调用  ⑤其中一个是 ep_poll_callback(epitem)
  ⑥它把该 epitem 挂入 rdllist（已在链表中则跳过 ⟹ 事件合并）
  ⑦唤醒阻塞在 eventpoll.wq 上的线程  ⑧epoll_wait 摘取就绪项，返回到用户态
  ★ 工作是在 ⑥ 做的，不是在 ⑧ 做的 ⟹ 代价只与"这次真正就绪了多少 fd"有关。

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12

LT（水平触发，默认）：条件持续满足就持续通知
  【就绪入链】─▶【返回就绪】─(还剩 1000 B 未读)─▶【再次返回】─ ...
  ★ 读不干净也安全；代价是 fd 长期未读干净时 epoll_wait 一直返回它（忙转）。
ET（边缘触发，EPOLLET）：只在就绪状态跃迁的那一刻通知一次
  【未就绪】─数据到达(0→有)─▶【通知一次】─读了 200 B─▶【不再通知】
                                    (还剩 800 B，状态没跃迁)
  ★ 剩下 800 B 必须自己循环读完；之后若又有新数据，会再触发一次边沿。
ET + 阻塞 fd 的死锁：最后一次 read 时数据已读完，阻塞 read 无法返回 EAGAIN
  ⟹ 线程在内核睡眠等"下一次数据到达"，而该边沿本来要靠它去 epoll_wait 才能
    拿到 ⟹ 线程卡死在 read 上，事件循环停摆，该线程照看的连接全部饿死。
  ★ 所以"ET 必须非阻塞"是逻辑必要条件：只有非阻塞 read 能用 EAGAIN 告诉你
    "这一轮读完了"，你也才有机会回 epoll_wait 等下一次边沿。

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16

// 为什么循环 + 判定 EAGAIN：ET 模式下内核只通知一次，
// "读多少"必须由应用负责到"确认再无数据"为止。
void handle_read(int fd) {                       // fd 必须在 epoll_ctl 之前设好
    char buf[8192];                              // fcntl(fd,F_SETFL,fl|O_NONBLOCK)
    for (;;) {
        ssize_t n = read(fd, buf, sizeof(buf));
        if (n > 0) { process(buf, n); continue; }    // 关键：不 break，继续榨干
        if (n == 0) { close(fd); return; }           // 0 是 EOF（对端关闭）
        if (errno == EINTR) continue;                // 被信号打断不算读完
        if (errno == EAGAIN || errno == EWOULDBLOCK) return;  // 唯一正确退出条件
        perror("read"); close(fd); return;           // 真错误
    }
}
// event_loop 里对每个就绪项分派，并必须处理 EPOLLHUP/EPOLLERR
// （没在 events 里申请也会被返回，忽略它会导致 fd 永不关闭、泄漏累积）
// 为什么用 EPOLLET：长连接下避免"未读干净的 fd 反复被返回"。

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11

write(fd, buf, n) 返回 n 之后，数据处于哪一层

  用户缓冲区 ─copy─▶ page cache（内存）─▶ 脏页标记 ─回写─▶ 磁盘/SSD 介质
       │                  │                  │                │
       │            write 返回成功            │                │
       │      （数据已进内核，对进程自身可见）  │                │
       │                    fsync()/fdatasync() 返回           │
       │                    （数据已到设备）                     │
       └────────── 顺序：write < fsync < 掉电安全 ──────────────┘
  ★ fsync 返回也不保证到达盘片持久介质：需硬件写缓存配合 FUA /
    写屏障，或在设备层禁用写缓存，才能保证掉电不丢。

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17

【方案一】传统 read + write：4 次拷贝（2 DMA + 2 CPU）+ 4 次上下文切换
  ①DMA 磁盘→page cache  ②CPU page cache→用户缓冲区  ③read 返回（切回用户态）
  ④CPU 用户缓冲区→socket 发送缓冲区  ⑤DMA socket 缓冲区→网卡  ⑥write 返回
  ★ 用户缓冲区只是"中转站"，数据完整走了一遍却又原样送出。
【方案二】mmap + write：3 次拷贝（1 CPU + 2 DMA）、2 次上下文切换
  ①mmap 建立映射（一次性）  ②CPU page cache→socket 发送缓冲区  ③DMA socket→网卡
  ★ 收益：省掉"页缓存→用户缓冲区"那一跳（两者共享同一份物理页）；残留：向
    socket 写，内核仍要拷进 socket 缓冲区再交给 DMA —— 这一跳还在。
【方案三】sendfile：无 DMA 收集 3 次拷贝，有 DMA 收集（SG-DMA）2 次
  (a) 不支持 scatter-gather：①DMA 磁盘→page cache ②CPU page cache→socket
      发送缓冲区 ③DMA socket→网卡 ⟹ 3 次拷贝（1 CPU + 2 DMA），数据不出内核
  (b) 支持 scatter-gather DMA（现代网卡普遍支持）：
      ①DMA 磁盘→page cache ②★CPU 只拷"描述符"（页地址+长度）到 socket 缓冲区，
        数据本身一个字节都不动 ③SG-DMA 按描述符从 page cache 直接→网卡
      ⟹ 2 次拷贝（0 CPU 数据拷贝 + 2 DMA）★ 这才是真正的"零 CPU 拷贝"
      ★ 这就是 sendfile 传静态大文件时 CPU 占用极低的原因，也是 Nginx 的
        sendfile 配置项背后的机制。

1
2
3
4
5
6

io_uring 的两个环形队列（用户态与内核态 mmap 同一块内存）
  用户态：SQ 提交队列 [SQE][SQE][SQE][ ]  CQ 完成队列 [CQE][CQE][ ][ ]
          tail↑写入 SQE、移动 tail       从 head 读 CQE
  内核态：从 SQ 取 SQE 异步执行 I/O，完成后写 CQE（用户态全程无系统调用）
  ★ 需内核介入时才用 io_uring_enter；开启 SQPOLL 后由内核线程轮询 SQ，
    连 io_uring_enter 都可以省掉。