文件系统
文件系统把磁盘组织成文件：名字、数据、元数据三层。面试主线：inode 机制、目录怎么存、崩溃恢复。
文件的三层抽象
| 层 | 内容 |
|---|---|
| 文件名 | 用户看到的路径（/home/user/a.txt） |
| inode | 元数据：权限、大小、时间戳、数据块位置 |
| 数据块 | 实际内容 |
inode 是核心：文件 = inode + 数据块。文件名只是 inode 的引用（目录项）。
inode 与文件查找
文件访问: 目录项 → inode → 数据块
- 目录就是文件：内容是“名字 → inode 号”的映射表
- 打开文件流程：路径逐级查目录（/ → home → user）→ 拿到 inode → 读数据块
- 大文件：inode 用直接指针 + 间接指针（一级/二级）寻址，支持超大文件
- 硬链接：两个目录项指向同一 inode（同一文件）；软链接：存目标路径的独立文件
文件系统结构（ext4 为例）
| 区域 | 作用 |
|---|---|
| 超级块 | 文件系统全局信息（大小、状态） |
| inode 表 | 所有 inode |
| 数据块区 | 实际内容 |
| 日志区（journal） | 崩溃恢复 |
日志（journaling）：写操作先记日志再落盘，崩溃后按日志重放，保证一致性。对比数据库的 WAL（见数据库 WAL 篇），同一思想。
页缓存与写回
- 页缓存（page cache）：读过的文件页留在内存，重复读免磁盘
- 写回策略：write 先写页缓存（标记脏页），内核后台刷盘线程（writeback）落盘
- 写回的代价：断电丢数据窗口（脏页没刷盘），sync/fsync 强制刷盘
- 面试点：fsync 是数据库可靠性的关键（PG 的 WAL 刷盘就是 fsync）
面试追问
- inode 是什么？ 文件的元数据 + 数据块指针。文件名只是目录项到 inode 的引用
- 硬链接和软链接？ 硬链接共享 inode（同一文件多个名字），软链接是存路径的独立文件（可跨文件系统）
- 文件系统怎么防崩溃？ 日志：先记后写，崩溃重放。和数据库 WAL 同思路
- 写回和 fsync？ 写页缓存延迟刷盘（性能），fsync 强制落盘（可靠性）。数据库靠 fsync 保数据
- 打开文件的过程？ 路径逐级查目录 → 找 inode → 读数据块。目录本身也是文件