VFS 与文件系统抽象

• 理解各文件系统的设计目标与核心特性
• 理解各文件系统适合的应用场景
• 理解从功能到性能的取舍

ext4 是 Linux 最常用的通用文件系统，稳定、兼容性好，支持 extent、延迟分配、日志，适合作为通用根文件系统与一般数据盘。xfs 以高并发和高扩展性著称，元数据操作与大量文件场景性能优异，适合大数据、数据库、大规模存储。btrfs 基于 CoW（写时复制），支持快照、子卷、压缩、checksum，适合需要这些高级功能的场景，但高负载下性能与稳定性需权衡。f2fs 专为 Flash（NAND）设计，采用 log-structured 与 FTL 友好设计，适合 SSD 与嵌入式闪存设备。ntfs3 用于访问 Windows NTFS，主要用于跨平台挂载 Windows 分区，而非 Linux 原生数据存储。选型要点：通用与稳定选 ext4，高并发大文件选 xfs，需要快照/子卷/压缩选 btrfs，闪存设备选 f2fs，跨平台读 Windows 盘选 ntfs3。

文件系统选型取决于工作负载（并发、文件大小、是否需要快照/压缩）与存储介质（机械盘、SSD、闪存）。理解各 FS 的强项与取舍，是存储与运维场景的核心决策依据。

• 理解路径解析逐分量进行（walk component）
• 理解符号链接解析与 MAXSYMLINKS 深度限制
• 理解 RCU-walk 与 ref-walk 两种模式

VFS 路径解析从根目录或当前目录开始，逐分量地对路径每一步做 lookup：在每个分量上，通过 dentry 名称在父目录的 dentry 缓存中查找（初始为 dcache 命中），未命中则调用文件系统的 lookup 回调从磁盘加载。若分量是符号链接，VFS 会读取链接目标并据此继续解析，内核限制符号链接展开深度（MAXSYMLINKS，通常 40）防止无限循环。跨挂载点时，路径解析会检查 dentry 上的挂载点，进入对应的根目录继续。为提高性能，内核提供 RCU-walk 模式：在无修改、无锁竞争的路径上，用 RCU 读锁在不持有锁的情况下快速遍历 dcache 与挂载点，避免拷贝引用；一旦遇到需要修改或锁竞争，就回退到传统的 ref-walk（持锁）模式。RCU-walk 显著加速了只读路径的解析。

路径解析是核心性能路径，RCU-walk 通过"无锁只读遍历"加速热点路径。理解逐分量 lookup、符号链接限制与跨挂载点处理，是掌握 VFS 抽象与性能的关键。

• 理解 shared/slave/private 的传播语义
• 理解 bind mount 的递归传播行为
• 理解容器卷场景下的选型

挂载传播决定一个挂载点在 namespace（或主机）之间的挂载/卸载事件如何传播。shared 挂载：挂载点加入一个 peers 组，组内任一处挂载/卸载事件都会向其他成员传播，适合共享目录（如需在多个 namespace 同步）。slave 挂载：从主挂载接收传播事件，但自身的事件不会反向传播到主，适合"单向跟随"场景。private 挂载：完全不传播，挂载事件彼此隔离。bind mount 的递归传播取决于其挂载类型：shared 的 bind 会递归传播到 peers，slave 只从主接收，private 则完全隔离。容器卷场景选型：默认容器根文件系统通常用 private 或 slave 避免宿主挂载意外泄漏到容器；需要容器内挂载与宿主同步（如 bind 宿主目录）时用 shared；需要单向（容器看宿主、宿主不影响容器）用 slave。容器运行时（如 Docker）默认对 / 使用 slave 或 shared，对卷 bind 灵活设置。

挂载传播是 namespace 隔离的正确性关键。理解 shared/slave/private 的传播方向，才能在容器卷、bind mount 场景下避免"挂载泄漏"或"看不见挂载"的问题。

• 理解 file_operations 对应文件对象操作（read/write 等）
• 理解 inode_operations 对应 inode 元数据操作（lookup/create 等）
• 理解 super_operations 对应超级块/super_block 操作

VFS 通过操作结构体（hooks）把具体文件系统实现抽象出来。file_operations（struct file_operations）描述对"打开的文件"的操作，包括 read、write、read_iter、write_iter、mmap、fsync、poll、open、release 等，挂载在 struct file 上，随每个打开的文件实例生效。inode_operations（struct inode_operations）描述对 inode 的元数据/目录操作，包括 lookup、create、mkdir、unlink、rename、link、getattr、setattr 等，用于路径解析与目录管理。super_operations（struct super_operations）描述对超级块（文件系统实例）的操作，包括 alloc_inode、destroy_inode、write_inode、sync_fs、statfs、put_super 等，用于 inode 生命周期与全局同步。各文件系统通过实现这些结构体来注册自己的能力，VFS 通过统一接口调用来完成系统调用。

这三组钩子是 VFS 抽象的具体体现：file 操作面向"已打开的文件流"，inode 操作面向"元数据与目录"，super 操作面向"文件系统实例"。理解它们能清晰地把握 VFS 层的职责划分。

• 理解各对象的职责
• 理解对象间的关联关系
• 理解它们如何映射到底层文件系统

VFS 通过四个核心对象抽象文件系统。super_block（超级块）代表一个已挂载的文件系统实例，保存全局信息（块大小、设备、根 inode 等）。inode 代表文件系统的元数据对象（一个文件/目录），保存权限、大小、时间戳、数据块映射等，与磁盘上的文件一一对应。dentry（目录项）代表路径中的一个分量，是目录与文件名的缓存项，用于加速路径解析，它引用 inode 并体现目录层级。file 代表一个已打开的文件实例，保存文件偏移、打开标志、权限等，与进程的打开文件描述符对应，一个 inode 可被多个 file 引用。关系：super_block 包含根 inode；dentry 通过 d_inode 指向 inode；file 通过 f_path 指向 dentry，进而找到 inode。四大对象是"挂载静态信息—文件元数据—路径缓存—打开实例"的分层抽象。

四大对象是理解 VFS 的骨架。inode 是"文件本身"，dentry 是"路径中的名字"，file 是"打开的一次访问"，super_block 是"整个文件系统"。它们之间的指针关系构成了 VFS 的完整模型。

• 理解 CoW 写数据时开新块而不覆盖
• 理解 subvolume 与 snapshot 的实现（共享元数据）
• 理解减少碎片的代价与关闭方式

btrfs 采用 copy-on-write（CoW）设计：写入数据时不是原地覆盖旧块，而是把新数据写入新的空闲块，再更新元数据指针指向新块，旧块在无引用后回收。这种设计保证了崩溃一致性（要么旧快照要么新数据），并支持无限快照。subvolume（子卷）是 btrfs 中的独立命名空间树，一个 btrfs 文件系统可包含多个子卷，各子卷可独立挂载、独立配额。snapshot（快照）是子卷在某个时间点的只读/可写副本，通过共享元数据块实现，创建几乎是 O(1) 且初始不占额外空间，只有后续修改才产生新块（CoW 的写时复制）。应用场景：系统升级前快照、文件版本管理、容器/虚拟机镜像。CoW 的代价是可能存在写放大与碎片，可通过 nodatacow 挂载选项或文件属性关闭。

CoW 是 btrfs 快照与一致性的根基，subvolume 提供独立的目录树，snapshot 利用共享元数据实现即时快照。理解这些能力与 CoW 的取舍，是选择 btrfs 的关键。

• 理解 dentry 是路径分量的缓存
• 理解 dcache 的 hot 与路径解析加速
• 理解 dcache 的失效与内存回收

dcache（dentry cache）是内核缓存目录项（dentry）的机制。每个路径分量（如 /a/b/c 中的 a、b、c）在首次解析时，内核会创建对应的 dentry 并缓存，后续再次访问相同路径时，直接从 dcache 命中，无需重复磁盘 lookup，从而大幅加速路径解析。dcache 以目录结构的树形组织，每个 dentry 挂在父目录的哈希链表中，支持按名快速查找。为提升命中率，内核还维护"最近不止一次访问"的 dentry 为 hot（热），避免被回收。dcache 由内存自动管理，受内存压力影响可被回收（如 drop_caches=2 或内存不足时）。当文件被删除或目录更新时，对应 dentry 会被标记失效以保持一致性。

dcache 是"路径查找的加速器"，把磁盘 lookup 转化为内存哈希查找。理解它的缓存逻辑与失效机制，是分析高 IO 场景下路径解析性能与内存占用（dcache 占用）的基础。

• 理解闪存的写前擦除、擦除块粒度特性
• 理解 f2fs 的 log-structured 与 segment/SSA 设计
• 理解 f2fs 的多级清理（GC）与磨损均衡

闪存（NAND）有"写前擦除、擦除按块、写放大、有限擦写寿命"等特性，f2fs 针对这些设计。它采用 log-structured 结构：把整块设备划分为多个 segment，所有数据顺序写入一个"当前写 segment"，避免随机小块写，减少写放大。f2fs 使用 SSA（Segment Summary Area）保存段内映射，并通过 NAT（Node Address Table）管理节点地址，实现 LBA 到 PBA 的映射，与 FTL 的映射机制互补。f2fs 把数据与节点分开管理，通过多级清理（GC，包括 foreground/background）回收 segment，并配合磨损均衡延长寿命。它还针对 FTL 预留了合适的粒度（如 4KB 对齐），并支持 inline data、多级 segment 等优化。这些设计减少了 FTL 层的写放大与擦除开销，提升闪存设备的 IO 吞吐与寿命。

f2fs 的核心是"顺着闪存的擦除块与顺序写特性设计"，用 log-structured 减少随机写、用 SSA/NAT 管理映射、用 GC 与磨损均衡保证寿命。理解它是掌握闪存存储优化的关键。

• 理解 inode 的元数据字段
• 理解 inode 的块映射结构（extent/间接块）
• 理解小文件与大文件的映射差异

inode 是文件元数据的载体，保存在磁盘上（如 ext4 的 inode table），包含：文件类型与权限、拥有者（uid/gid）、大小、时间戳（atime/mtime/ctime）、链接计数、以及数据块的映射信息。块映射结构因文件系统而异：ext4 用 extent（extent tree）表示连续的逻辑块区间，每个 extent 记录起始物理块号与长度，一个 inode 内嵌多个 extent，超出时用 extent tree 索引；传统 ext2/3 用间接块（单倍/双倍/三倍间接）逐级映射。文件的 inode 通过 i_blocks 与映射结构，把逻辑偏移映射到物理块地址。小文件（如 <60 字节）甚至可以把数据直接内嵌在 inode 中（inline data），避免额外磁盘块访问。映射查询是每次读写都要进行的核心操作，因此 extent 相比间接块大幅减少间接寻址。

inode 元数据 + 块映射是"文件如何对应到磁盘"的核心。理解 extent 与间接块的区别、inline data 的优化，是分析文件系统 IO 与空间管理的重点。

• 理解 fsync 刷盘的是脏页与元数据
• 理解数据与元数据的写回顺序
• 理解日志/journal 对崩溃一致性的作用

fsync 的目的是把文件的数据与元数据持久化到磁盘，保证崩溃后数据不丢失。page cache 中的 dirty 页在 fsync 时被写回磁盘，但为了保证崩溃一致性，写回顺序很关键：通常会先写数据块，再写元数据（inode 大小、时间戳等），并在提交事务（journal）中记录操作。若先写元数据后写数据，崩溃时可能元数据指向未写入的数据块导致损坏；若先写数据后写元数据，则安全。ext4 等文件系统通过 journal（日志）实现崩溃一致性：先把事务（元数据+数据变更）写入 journal 日志区，再写回实际位置，崩溃时通过重放日志恢复。因此 fsync 需要等待数据与元数据都落盘，开销较大。为提升性能，可用 fdatasync 只刷数据（跳过不必要元数据），或使用 barrier 与 journal 的 ordered 模式控制顺序。

崩溃一致性依赖"日志 + 顺序写回"。理解 fsync 刷盘的数据/元数据顺序与 journal 机制，是掌握数据库、文件系统可靠性与 fsync 性能开销的关键。

• 理解 MS_NOATIME 关闭访问时间更新
• 理解 MS_NODIRATIME 关闭目录访问时间更新
• 理解 MS_LAZYTIME 延迟更新时间戳

这些挂载标志控制文件时间戳（尤其 atime 访问时间）的更新策略。MS_NOATIME：关闭文件的访问时间（atime）更新，读文件不再写 atime，减少写盘与 I/O 开销，适合读密集的日志、缓存目录。MS_NODIRATIME：只关闭目录的 atime 更新，文件仍更新，适合不希望目录访问产生写 IO 的场景。MS_LAZYTIME：延迟更新 atime/mtime/ctime，把时间戳更新推迟到内存中，仅在必要时（如 inode 被写回、被其他进程读取 ctime/或文件关闭）才落盘，从而减少频繁时间戳更新带来的写 IO，同时尽量保持语义正确。选择上：追求极致读性能用 NOATIME，只想避免目录更新用 NODIRATIME，希望在正确性与性能间平衡用 LAZYTIME。它们常与 relatime（相对访问时间）配合。

atime 更新是隐藏的写 IO 来源，这些标志在保证语义或牺牲少量正确性的前提下减少写盘。理解它们适用于日志、缓存、只读目录等场景的调优。

• 理解 /proc 与 /sys 是内核暴露信息的虚拟文件系统
• 理解 /proc 面向进程与内核状态、/sys 面向设备与子系统
• 理解其数据的动态生成与读写回调

/proc 与 /sys 都是虚拟文件系统（pseudo/virtual filesystem），它们不占用磁盘，其"文件"在访问时由内核动态生成，用于暴露内核与系统状态、提供接口。Linux 用 procfs 与 sysfs 实现。procfs（/proc）以进程为中心，提供每个进程的目录（/proc//）与内核全局状态（如 /proc/meminfo、/proc/cpuinfo、/proc/sys/ 下的可调参数），并支持部分可写文件（如 /proc/sys/vm/...）用于运行时配置。sysfs（/sys）以设备与内核子系统为中心，把设备、驱动、总线、块设备等建模为目录与属性文件（如 /sys/class/、/sys/block/），用于设备管理与系统配置。两者的实现都通过注册操作回调（read/write 时动态计算）而非存储真实数据，因而读取时能看到实时状态。VFS 抽象让它们与普通文件系统一样可被 open/read 访问。

/proc 与 /sys 是"内核看世界的窗口"，通过 VFS 把动态数据映射为文件。理解它们面向对象不同（进程 vs 设备）与动态生成机制，是内核监控与调优的基础。

• 理解 inotify 按目录/文件监控事件
• 理解 fanotify 支持全局文件系统监控与权限事件
• 理解两者的权限与用途差异

inotify 与 fanotify 都用于监控文件系统事件，但能力不同。inotify 是面向单进程的轻量级监控：进程通过 inotify_add_watch 对特定文件或目录添加监视，接收打开、关闭、修改、删除、移动等事件（inotify 事件），适合应用内文件变更监听（如文件同步、编辑器重载）。它不通知"谁"访问，且监控范围有限。fanotify 是更强大的机制：可对整个文件系统进行全局监控（fanotify_mark 挂载点或目录），支持权限事件（FAN_OPEN_PERM、FAN_ACCESS_PERM），能在访问和修改文件前/后回调，并可返回决策（允许/拒绝），因此可用于安全审计、实时病毒扫描、文件访问控制。fanotify 通常需要 CAP_SYS_ADMIN 或相关权限，而 inotify 普通用户即可用。fanotify 功能更强但开销更大。

inotify 面向"应用内轻量监听"，fanotify 面向"系统级监控与权限控制"。理解二者差异，在文件同步、杀毒、审计等场景中正确选型。

• 理解两者都驻留内存、可动态增长
• 理解 tmpfs 可 swap、有大小的 size 限制
• 理解 ramfs 无大小限制、不可 swap

tmpfs 与 ramfs 都是把文件放在内存（RAM）中的文件系统，读写速度快，常用于 /tmp、/dev/shm、容器卷等。二者的关键差异：tmpfs 基于 page cache 但页面可被 swap 换出，且支持 size 限制（mount 时指定大小，默认使用内存的一半），超过限制会报错 ENOSPC；它把数据放 page cache，压力大时内核可回收。ramfs 没有大小限制，数据固定在内存中，不可 swap，且没有基于比例的限制，因此可能无限增长直至内存耗尽（OOM）。应用上：临时文件、共享内存（/dev/shm）用 tmpfs（有回收与大小控制更安全）；需要保证数据一直在内存、绝对不 swap 的场景用 ramfs（但需严防填满内存）。tmpfs 更常用，因为其可回收与可限制特性更安全。

核心差异是"可 swap + 可限制大小"（tmpfs）vs "不可 swap + 无限制"（ramfs）。理解这一点决定了生产环境选 tmpfs 而非 ramfs，以避免内存耗尽风险。

• 理解 FUSE 把文件系统实现移到用户态
• 理解 FUSE 的性能开销（多次上下文切换与会话）
• 理解 FUSE 的适用场景

FUSE（Filesystem in Userspace）允许用户态程序实现文件系统，而无需修改内核。内核的 fuse 模块负责把 VFS 请求转发到用户态守护进程（通过 /dev/fuse 与协议消息），用户态进程处理请求并返回结果。这样开发者可以用普通语言实现文件系统，但代价是性能开销：每次 IO 需要内核-用户态多次上下文切换与消息传递，延迟显著高于内核原生文件系统，也缺少内核级缓存与优化。为缓解，FUSE 支持 fuse cache（dcache/inode 缓存）、writeback cache、readahead 等。适用场景：需要快速开发的文件系统（如加密文件系统、网络文件系统、云存储挂载、FTP/SFTP 挂载、用户目录）、容器卷插件、以及需要灵活逻辑的存储方案。对性能敏感的核心存储仍应使用内核文件系统。

FUSE 的价值是"开发成本低、灵活"，代价是"性能与开销"。理解其上下文切换开销与缓存优化手段，能在"快速实现"与"高性能"之间做出正确选择。

• 理解 overlayfs 的 lowerdir/upperdir/merged
• 理解 copy-up 与写时复制
• 理解容器镜像层与存储驱动

overlayfs 是一种 union filesystem（联合挂载），把多个目录（层）叠加成一个合并视图。它有三层概念：lowerdir（底层只读目录，可多个）、upperdir（上层可写目录）、merged（合并挂载点，用户看到的视图）。读取时按 lowerdir 到 upperdir 顺序查找；写入时如果目标在 lowerdir，overlayfs 会执行 copy-up：把文件从 lowerdir 复制到 upperdir，再在 upperdir 上修改，从而保证 lowerdir 只读不变。这就是"写时复制"（CoW）的目录层实现。容器镜像正是基于此：镜像的每一层作为 lowerdir（只读），容器运行时的可写层作为 upperdir，多个镜像层联合成一个可写文件系统。删除 lowerdir 中的文件时用 whiteout 标记隐藏。容器运行时（如 Docker 的 overlay2 驱动）利用 overlayfs 实现镜像层的叠加与共享。

overlayfs 的 copy-up 与 whiteout 让它以"只读底层 + 可写上层"实现 CoW，这是容器镜像层共享与隔离的基础。理解它就能理解容器存储驱动的原理。

• 理解 O_TMPFILE 一次性创建匿名文件
• 理解 tmpnam+unlink 的竞态与安全问题
• 理解原子性与安全性优势

O_TMPFILE 是 open 的一个标志，允许在指定目录内创建"匿名"临时文件：open 时返回一个未链接到文件系统的文件描述符，文件没有名字，写入内容后可通过 linkat 以原子方式把它链接到目录中（或直接关闭丢弃）。相比传统的 tmpnam+unlink 方案（先生成随机文件名，再 open，之后 unlink，进程保持 fd），O_TMPFILE 的优势：原子性——文件从创建起就不出现在目录中，避免"先创建后 unlink"时间段内被其他进程看到或访问的竞态窗口；安全性——无需显式生成随机名，避免符号链接攻击（symlink attack）与 TOCTOU 竞态，因为根本不创建有名字的文件；开销——省去中间命名与 unlink 步骤。O_TMPFILE 还要求目录支持（需 FS 支持 O_TMPFILE），创建后可通过 linkat 命名。

O_TMPFILE 的核心是"从未命名到命名"的原子性，消除了临时文件创建与链接之间的竞态窗口，同时避免符号链接炸弹等安全问题。理解它优于 tmpnam+unlink 是关键。

• 理解 extent 表示连续块区间
• 理解 delayed allocation 延迟分配磁盘块
• 理解两者对性能与碎片的影响

ext4 用 extent mapping 替代传统的间接块映射：extent 表示一段连续的物理块区间（起始块号 + 长度），一个 inode 内嵌多个 extent（ext4 默认 4 个），超出时用 extent tree 索引。相比间接块逐级寻址，extent 能把连续的多块映射为一条记录，减少寻址开销、提升大文件连续读写性能。delayed allocation（延迟分配）是延迟"何时分配磁盘块"到真正写盘或 fsync 时：应用 write 时，ext4 只预约逻辑块、不立即分配物理块，待到刷新（flusher）或需要落盘时才批量分配。其好处是能聚合多个小的写入，按连续顺序分配，减少碎片、避免"先分配后覆盖"的浪费，提升性能。代价是数据如果在崩溃前未 fsync，可能因块未分配而丢失，因此需要日志配合。两者结合使 ext4 在连续与大文件场景表现优秀。

extent 减少映射开销，delayed allocation 减少碎片并聚合写。理解二者是把握 ext4 性能特性与 fsync 语义的关键。

• 理解 xfs 用 B+ 树管理 inode/空闲空间
• 理解 xfs 的可扩展日志、延迟日志与元数据优化
• 理解 xfs 在大规模场景的优势

xfs 以高可扩展性和大文件系统支持著称。它使用 B+ 树管理元数据，包括 inode 分配（inode B-tree）、空闲空间（free space B-tree，分 by block 与 by size 两棵）、以及 extent 映射（extent B-tree），使在大文件系统上的查找、分配与删除操作高效，支持 PB 级文件系统。xfs 的日志（journal）设计先进：日志是循环缓冲，可在线扩展（xfs_growfs），支持延迟日志（metadump、log recovery check）与日志记录优化；xfs 通过日志记录元数据变更以保证崩溃一致性，并尽量用 ordered 写减少日志写。xfs 还支持延迟分配（delalloc）、大块（global buffer）、以及按需磁盘分配。整体上，xfs 适合高并发、大文件的场景，其 B+ 树让元数据操作在文件数多时依然高效。

xfs 的 B+ 树结构化元数据与可扩展日志，是它在海量文件与高并发下的优势来源。理解其设计是掌握 xfs 选型与调优的基础。

• 理解 inode 的引用计数（i_count）
• 理解 iput 与 final iput 的释放条件
• 理解删除但仍打开的文件行为

inode 的生命周期由引用计数（i_count）管理。每有一个持引用者（如打开的文件、dentry、页面缓存等），i_count 增加；当引用释放时调用 iput 递减。当 i_count 归零（且无其他引用）时，触发 final iput，此时 inode 才真正被释放（销毁 inode 对象、释放内存、清理缓存）。删除仍被打开的文件时，unlink 会移除目录项并减少链接计数（i_nlink），但 inode 仍被打开的文件描述符持有引用，i_count 不为零，因此 inode 不会被立即释放——文件内容仍可通过已打开的 fd 访问，直到最后一个 fd 关闭（drop 最后一个引用）后，final iput 才会真正释放 inode 及其数据块。这正是"Linux 中删除文件仍可继续读写"的原因。内核通过 i_count 与 i_nlink 的协同（link 计数决定是否还可见，count 决定何时释放内存）管理生命周期。

i_nlink 是"有多少名字指向它"，i_count 是"有多少内存引用它"。删除只减 nlink，真正的内存释放要等 i_count 归零。理解这一协同是掌握文件删除语义与 inode 缓存回收的关键。