文件系统与页缓存
03-操作系统2026/11/14
文件名不在 inode 里，读文件也不一定碰磁盘——页缓存和目录项这两件事，决定了构建工具第二次为什么快。
同一份代码第一次 webpack --watch 要 30 秒，改一行再构建只要 2 秒，很多人以为是缓存插件神了。真正起作用的是三样东西：webpack 的持久化缓存文件、操作系统的 page cache、以及 node_modules 的目录项已经在内存里。
inode 与目录项
文件系统把「元数据」和「文件名」拆开存：
- inode（index node）存一个文件的所有元数据：类型、权限、uid/gid、大小、三个时间戳（atime/mtime/ctime）、链接数、数据块指针。它不存文件名。
- 目录项 dentry 存「文件名 → inode 号」的映射。目录本身也是一个文件，内容是这张映射表。
所以 open("/a/b.js") 是逐级解析路径：先在根目录的映射表里找 a 的 inode，再从 a 的目录数据里找 b.js。内核用 dcache 缓存这些解析结果，这也是为什么遍历十万个文件的目录特别慢——每个目录项都要查一次。
ls -li # 第一列就是 inode 号
stat package.json # 看 inode、块数、三个时间戳
df -i # 看 inode 使用率：磁盘没满也可能 inode 用尽
硬链接与软链接
| 维度 | 硬链接 hard link | 软链接 symbolic link |
|---|---|---|
| inode | 与源文件相同 | 独立 inode |
| 内容 | 就是同一份数据块 | 存的是目标路径字符串 |
ls -l 显示 | 普通文件，链接数 +1 | l 类型，带 -> target |
| 跨文件系统 | 不行 | 可以 |
| 指向目录 | 一般不允许 | 可以 |
| 源文件删除后 | 数据仍在，直到链接数为 0 | 变成悬空链接（dangling） |
ln report.txt report-hard.txt # 硬链接：两个名字，一份数据
ln -s report.txt report-soft.txt # 软链接：一个存路径的小文件
rm report.txt # 硬链接仍可读；软链接失效
pnpm 的核心就是把同一个包硬链接进不同项目的 node_modules，磁盘上只存一份，安装速度也因此快得多。
页缓存：读文件为什么快
内核把磁盘上的文件按 4 KB 页缓存在内存里，就是 Page Cache。read() 的实际动作是：
- 在 page cache 里找对应页，命中则直接
copy_to_user到你的缓冲区，不碰磁盘 - 未命中则发起磁盘 IO，读入整页（还会预读后面几页，readahead），再拷贝
- 写入时先写 page cache 并标脏，由内核的回写线程按
dirty_ratio、dirty_expire_centisecs异步刷盘
free -h 里的 buff/cache 就是它。它几乎会用满空闲内存，但随时可回收，不是「内存泄漏」。缓存命中时一次读只要几微秒，未命中机械盘要几毫秒，差三个数量级。
readFile 与 createReadStream
import { readFile, createReadStream } from 'node:fs'
// 一次性读入：内存峰值 ≈ 文件大小，还会多一份拼接缓冲
const buf = await readFile('./huge.log')
// 流式：内存峰值 ≈ highWaterMark（默认 64 KB）
createReadStream('./huge.log', { highWaterMark: 64 * 1024 })
.on('data', (chunk) => { /* 处理一块 */ })
.on('end', () => {})