汕头网站建设方案书_沈阳公司_网站软文推广网站_seo优化

1. 引言：Linux 虚拟文件系统 (VFS)

Linux 内核中的虚拟文件系统（Virtual File System, VFS），有时也被称为虚拟文件系统切换（Virtual Filesystem Switch），是内核中一个至关重要的软件层。它的核心目标是为用户空间应用程序提供统一的文件系统接口，同时在内核内部提供一个抽象层，使得各种不同的文件系统实现（例如 ext4, XFS, Btrfs, NFS, FAT, NTFS, procfs, sysfs 等）能够共存并协同工作。VFS 使得用户程序可以通过标准的系统调用（如 open(2), read(2), write(2), stat(2), close(2) 等）与文件进行交互，而无需关心底层文件系统的具体实现细节。这些系统调用通常在进程上下文中被调用。

VFS 的这种设计体现了经典的抽象和封装思想。它将具体文件系统的复杂性隐藏在一个通用接口之后，极大地简化了新文件系统的开发和集成。从功能上看，VFS 扮演着用户空间请求与特定文件系统实现之间的桥梁角色。当用户程序发起一个文件操作请求时，VFS 接收该请求，并通过一系列内部机制将其转换为对底层具体文件系统驱动程序的调用。

为了实现这种通用性，VFS 定义了一组核心的数据结构，用于表示文件系统的不同方面。其中最主要的四个对象是：super_block（超级块），代表一个已挂载的文件系统实例；inode（索引节点），代表磁盘上的一个文件或目录等文件系统对象；dentry（目录项），代表一个目录条目，连接文件名和 inode；以及 file（文件对象），代表一个由进程打开的文件实例。此外，file_system_type 结构用于注册和管理不同的文件系统类型，而 address_space 结构则在管理文件数据的页缓存（page cache）和处理 I/O 操作中扮演关键角色。

VFS 采用了面向对象的设计方法。每个核心实体（如 super_block, inode, dentry, file）不仅包含描述其状态的数据，还包含一个指向操作表（*_operations 结构）的指针。这些操作表包含了一系列函数指针，定义了可以在该对象上执行的操作。VFS 的通用代码通过调用这些操作表中的函数，将具体的操作委托给底层文件系统实现。例如，当 VFS 需要读取一个 inode 时，它会调用 super_block->s_op->read_inode（在旧版本内核中）或通过 iget 机制间接调用文件系统特定的函数。这种机制使得 VFS 核心代码能够保持通用性，同时允许每个文件系统实现其特有的行为。

VFS 的设计在提供强大抽象能力的同时，也必须关注性能。直接与特定文件系统交互可能更快，但 VFS 的抽象层引入了一定的间接性。为了弥补这种潜在的开销并提供高性能，VFS 大量依赖于缓存机制。其中，目录项缓存（dentry cache 或 dcache）用于加速路径名解析，而页缓存（page cache）则用于缓存文件数据，减少磁盘 I/O。这些缓存机制与 VFS 的核心数据结构紧密集成，是理解 VFS 性能特征的关键。本报告将深入分析这些核心数据结构，阐述它们的用途、关键字段、在文件系统操作中的作用，以及它们之间的相互关系和交互流程。

2. super_block 对象：文件系统实例的表示

super_block 结构是 VFS 中代表一个已挂载（mounted）文件系统实例的核心对象。每当一个文件系统被挂载到 VFS 目录树中时，内核就会在内存中创建一个对应的 super_block 结构实例。这个结构体聚合了管理该挂载点所需的所有全局信息。

对于基于磁盘的文件系统（如 ext4, XFS），内存中的 super_block 对象通常对应于存储介质上特定区域（通常是文件系统的起始块）的物理“超级块”或“文件系统控制块”。这个物理超级块存储了文件系统的持久元数据。VFS 在挂载时读取这些元数据，并填充到内存中的 struct super_block 结构中。对于虚拟文件系统（如 procfs, tmpfs），它们没有物理存储介质，因此 super_block 对象及其内容完全在内存中创建和维护。

2.1 super_block 的关键字段

struct super_block 包含了描述文件系统实例状态和属性的众多字段。以下是一些关键字段及其作用：

字段名	类型	描述
s_fs_info	void *	指向文件系统特定的超级块信息。不同文件系统（如 ext4）可以用它来存储标准 super_block 结构之外的私有数据。在现代挂载 API 中，通过 fs_context->s_fs_info 进行设置。
s_root	struct dentry *	指向该挂载文件系统的根目录对应的 dentry 对象。这是 VFS 访问该文件系统层级结构的入口点。通常在 fill_super 函数中通过 d_make_root 创建并设置。
s_op	const struct super_operations *	指向超级块操作表的指针。该表包含了一系列函数指针，定义了 VFS 可以对该文件系统实例执行的操作（如分配/销毁 inode、写回 inode、获取统计信息等）。
s_type	struct file_system_type *	指向描述该文件系统类型的 file_system_type 结构的指针。
s_flags	unsigned long	包含挂载标志（如 SB_RDONLY）和 VFS 内部状态标志。例如，MS_SYNCHRONOUS 表示同步写入。现代挂载 API 通过 fs_context 中的 sb_flags 和 sb_flags_mask 来管理这些标志。
s_magic	unsigned long	文件系统的魔数，用于在挂载时识别文件系统类型。例如，ext2/3/4 的魔数是 0xEF53。
s_blocksize	unsigned long	文件系统的块大小（以字节为单位）。
s_blocksize_bits	unsigned char	文件系统块大小的位数（即 log2(s_blocksize)）。
s_maxbytes	loff_t	该文件系统支持的最大文件大小。
s_dev	dev_t	对于基于块设备的文件系统，表示其所在的设备标识符。对于非设备文件系统，通常为 0。
s_id	char	文件系统的标识符字符串，通常是挂载时使用的设备名称或源字符串。
s_uuid	uuid_t	文件系统的通用唯一标识符（UUID）。
s_dirty	struct list_head	连接该文件系统上所有脏 inode 的链表头。用于写回操作。
s_umount	struct rw_semaphore	读写信号量，用于在卸载操作期间保护超级块，防止文件系统在操作过程中被卸载。
s_writers	struct sb_writers	管理写操作计数器和等待队列，用于文件系统冻结（freeze）保护。sb_start_write() 和 sb_end_write() 使用它来确保写操作与冻结操作互斥。
s_export_op	const struct export_operations *	指向 NFS 导出操作表的指针，用于支持通过 NFS 导出文件系统。

2.2 super_block 在挂载过程中的作用

super_block 对象的创建和初始化是文件系统挂载过程的核心环节。当用户请求挂载一个文件系统时（例如通过 mount(2) 系统调用），VFS 会执行以下步骤：

1. 查找文件系统类型：VFS 根据用户指定的类型名称（或通过探测）找到对应的 struct file_system_type 对象。
2. 调用 mount 方法：VFS 调用该 file_system_type 结构中的 mount 函数指针。
3. 通用挂载辅助函数：mount 方法通常不会直接实现所有逻辑，而是调用 VFS 提供的通用辅助函数，如 mount_bdev（用于块设备文件系统）、mount_nodev（用于无设备文件系统）或 mount_single（用于单实例文件系统）。
4. 分配 super_block：这些辅助函数会分配一个新的 struct super_block 内存对象，并进行部分初始化（例如设置 s_dev）。
5. 调用 fill_super：关键步骤是调用由具体文件系统提供的 fill_super 回调函数。fill_super 函数负责完成 super_block 的初始化。
   • 读取物理超级块：对于磁盘文件系统，fill_super 通常需要从块设备读取物理超级块的内容。这可能涉及到使用缓冲缓存（buffer cache）提供的函数，如 sb_bread()（读取一个超级块相关的块）。
   • 填充字段：fill_super 使用从物理超级块读取的信息（或对于虚拟文件系统，使用默认/计算值）来填充内存中 struct super_block 的各个字段，包括 s_magic, s_blocksize, s_maxbytes 等。
   • 设置操作表：一个非常重要的任务是设置 s_op 字段，使其指向该文件系统实现的 super_operations 结构。
   • 获取根 Inode：fill_super 必须找到或创建文件系统的根 inode。
   • 创建根 Dentry：使用获取到的根 inode，调用 d_make_root() 函数来创建根目录的 dentry 对象，并将其赋值给 super_block->s_root。
6. 返回根 Dentry：mount 方法（或其调用的辅助函数）最终返回新创建或找到的根 dentry。VFS 随后将这个 dentry 与挂载点关联起来。

现代挂载 API：较新版本的内核引入了基于 fs_context 的挂载 API。这个 API 将挂载过程分解为更细粒度的步骤。文件系统通过实现 file_system_type 中的 init_fs_context 和 parameters 字段来参与这个过程。init_fs_context 初始化一个 struct fs_context，用于收集挂载参数。参数被逐个解析并添加到 fs_context 中。之后，VFS 调用 sget_fc()（或其他基于 fs_context 的辅助函数）来获取或创建 super_block。sget_fc() 会将 fs_context 中的相关信息（如 fc->s_fs_info, fc->sb_flags）传递给新的或已存在的 super_block。这种方式提供了更灵活、更结构化的参数处理和超级块管理。

2.3 super_operations 结构 (s_op)

super_operations 结构定义了 VFS 可以对特定文件系统实例（通过其 super_block）执行的各种高级操作。它是一个函数指针表，由具体的文件系统实现。

以下是一些关键的 super_operations 方法：

方法名	描述
alloc_inode	分配一个新的 VFS inode 结构。文件系统通常会分配一个包含 struct inode 的更大结构（如 ext4_inode_info），并进行基本初始化。由 alloc_inode() 调用。
destroy_inode	释放 alloc_inode 分配的资源。
free_inode	在 RCU 回调中释放 inode 内存，通常与 destroy_inode 配合使用。
dirty_inode	当 inode 的元数据（非数据）被修改并标记为脏时调用。
write_inode	将 inode 的元数据写回持久存储。VFS 在需要同步 inode 时调用此方法。
evict_inode	从 VFS 缓存中彻底移除 inode，包括清理其关联的页缓存页面（使用 truncate_inode_pages_final()）。
put_super	在文件系统卸载时调用，用于释放 super_block 及其私有数据（s_fs_info）占用的资源。由 file_system_type->kill_sb 触发。
sync_fs	将该文件系统实例的所有脏数据（inode、数据页等）写回存储设备。
freeze_fs/unfreeze_fs	冻结/解冻文件系统，使其进入或离开一致性状态，常用于 LVM 快照等场景。freeze_super/thaw_super 是不获取 s_umount 锁的版本。
statfs	获取文件系统的统计信息（如总空间、可用空间、inode 数量等），用于实现 statfs(2) 和 fstatfs(2) 系统调用。
remount_fs	处理文件系统的重新挂载请求（例如，改变挂载选项，如从只读变为读写）。
show_options	生成用于在 /proc/mounts 或 /proc/<pid>/mountinfo 中显示的挂载选项字符串。
quota_read/quota_write	读写文件系统的配额（quota）文件。

除非特别说明，这些操作通常在没有持有 VFS 锁的情况下被调用，并且是在进程上下文中执行，允许它们阻塞。

super_block 作为 VFS 中已挂载文件系统的核心代表，起着承上启下的关键作用。它不仅存储了文件系统的全局状态和属性，还通过 s_op 指针提供了 VFS 与具体文件系统实现交互的操作接口。同时，它通过 s_root 指针作为文件系统目录树的入口，并通过 s_fs_info 关联文件系统特定的数据。它的生命周期与文件系统的挂载状态紧密绑定，由 file_system_type 的 mount 和 kill_sb 操作进行管理。理解 super_block 是掌握 VFS 如何管理不同文件系统实例的基础。

3. inode 对象：文件系统对象的元数据

inode（索引节点）对象是 VFS 中用于表示具体文件系统对象的关键数据结构。这里的“文件系统对象”是一个广义的概念，包括普通文件（regular files）、目录（directories）、符号链接（symbolic links）、设备文件（device files）、管道（pipes）、套接字（sockets）等。

inode 的核心作用是存储与其所代表的文件系统对象相关的元数据（metadata）。这些元数据包括对象的类型、访问权限、所有者（用户 ID 和组 ID）、大小、各种时间戳（访问时间、修改时间、状态改变时间）以及指向存储对象实际内容的物理数据块的指针或映射信息。需要特别注意的是，inode 本身不包含文件名信息；文件名与 inode 的关联是由 dentry（目录项）对象来处理的。

inode 具有双重存在形式：

1. 磁盘上的 inode：对于持久化文件系统（如 ext4, XFS, Btrfs），每个文件或目录在磁盘上都有一个对应的 inode 结构，存储在文件系统的特定区域（如 inode 表）。
2. 内存中的 struct inode：当 VFS 需要访问某个文件系统对象时，它会读取磁盘上的 inode 信息，并在内存中创建一个 struct inode 对象来表示它。对于非持久化（内存或虚拟）文件系统（如 tmpfs, procfs），inode 对象仅存在于内存中。VFS 的 struct inode 是一个通用结构，旨在覆盖所有支持的文件系统类型的共性。

3.1 inode 与 super_block 的关系

inode 对象与其所属的文件系统实例（由 super_block 代表）之间存在紧密的联系：

• 归属关系：每个内存中的 inode 对象都明确地属于一个特定的 super_block。inode 结构中包含一个指向其所属 super_block 的指针，即 i_sb 字段。这表明了该 inode 属于哪个挂载的文件系统。
• 生命周期管理：inode 对象的分配和释放是由其所属文件系统的 super_block 来管理的。super_block 的操作表 s_op 中包含了 alloc_inode 和 destroy_inode（或 evict_inode）等方法，VFS 通过调用这些方法来创建和销毁特定文件系统的 inode 对象。例如，当 VFS 需要一个新的 inode 时（如创建文件），它会调用 s_op->alloc_inode；当 inode 不再被使用且需要从缓存中移除时，会调用 s_op->evict_inode。
• 缓存关联：super_block 结构中通常维护着与该文件系统实例相关的 inode 列表，例如 s_dirty 链表，用于跟踪所有需要写回磁盘的脏 inode。

3.2 inode 的关键字段

struct inode 结构包含了描述文件系统对象元数据和状态的众多字段。以下是一些关键字段：

字段名	类型	描述
i_ino	unsigned long	Inode 号。在所属的文件系统内唯一标识该 inode。
i_mode	umode_t	文件类型（如 S_IFREG 普通文件, S_IFDIR 目录, S_IFLNK 符号链接等）和访问权限位（读/写/执行权限）。
i_op	const struct inode_operations *	指向 inode 操作表的指针。定义了对 inode 本身进行操作的方法（如目录查找 lookup、创建文件 create、创建链接 link 等）。具体的操作集取决于 i_mode 中定义的 inode 类型。
i_fop	const struct file_operations *	指向文件操作表的指针。定义了对打开的文件进行操作的方法（如 read, write, mmap, fsync 等）。当文件被打开时，这个指针会被复制到 struct file 的 f_op 字段。
i_mapping	struct address_space *	指向与该 inode 关联的 address_space 对象的指针。address_space 对象负责管理该 inode 数据的页缓存和 I/O 操作。对于没有数据内容的对象（如某些特殊文件），此字段可能为 NULL。
i_sb	struct super_block *	指向该 inode 所属文件系统的 super_block 对象的指针。
i_nlink	unsigned int	硬链接计数。表示有多少个 dentry（文件名）指向这个 inode。当 i_nlink 降为 0 且 i_count（内存引用计数）也为 0 时，inode 及其数据块可以被回收。对于不支持硬链接的文件系统，此值通常为 1。Ext4 的 DIR_NLINK 特性允许目录的链接数超过限制，此时该字段可能设为 1。
i_uid	kuid_t	文件所有者的用户 ID。
i_gid	kgid_t	文件所有者的组 ID。
i_size	loff_t	文件的大小（以字节为单位）。对于目录或符号链接，其含义可能不同。
i_atime	struct timespec64	最后访问时间。
i_mtime	struct timespec64	最后修改时间（文件内容）。
i_ctime	struct timespec64	最后状态改变时间（元数据，如权限、所有者或内容修改）。
i_count	atomic_t	内存中 struct inode 对象的引用计数。当 VFS 代码使用一个 inode 时，会增加此计数；使用完毕后减少。当 i_count 降为 0 时，inode 对象可以从内存中回收。
i_flags	unsigned int	Inode 标志，如 S_IMMUTABLE（不可变）、S_APPEND（仅追加）等。
i_private	void *	指向文件系统特定的 inode 数据。通常指向一个 struct <fsname>_inode_info 结构，用于存储 VFS 通用结构之外的私有信息。
i_state	unsigned long	Inode 的内部状态标志，如 I_DIRTY（inode 元数据已修改，需要写回）、I_NEW（inode 是新创建的，尚未完全初始化）等。
i_rdev	dev_t	如果 inode 代表一个设备文件，此字段存储设备号。

3.3 Inode 操作 (inode_operations, i_op)

i_op 字段指向的 inode_operations 结构定义了直接作用于 inode 本身或其所代表的目录结构的操作。这些操作通常由文件系统实现，并且其可用性取决于 inode 的类型（i_mode）。

以下是一些常见的 inode_operations 方法：

方法名	描述
create	在目录下创建一个新的普通文件 inode 和 dentry。由 creat() 和 open(O_CREAT) 系统调用触发。
lookup	在目录（由 dir inode 表示）中查找指定名称（在 dentry 中）对应的 inode。这是路径名解析的关键步骤。如果找到，需要填充 dentry 指向找到的 inode；如果未找到，返回错误。
link	为一个已存在的 inode (old_dentry->d_inode) 在指定的目录 (dir) 中创建一个新的硬链接（新的文件名在 dentry 中）。会增加 inode 的 i_nlink 计数。
unlink	从目录 (dir) 中移除一个硬链接（由 dentry 指定）。会减少 inode 的 i_nlink 计数。
symlink	在目录 (dir) 中创建一个符号链接（名称在 dentry 中），指向路径 symname。
mkdir	在目录 (dir) 中创建一个新的子目录（名称和模式在 dentry 和 mode 中）。
rmdir	从目录 (dir) 中移除一个空的子目录（由 dentry 指定）。
mknod	在目录 (dir) 中创建一个特殊文件（设备文件、命名管道或套接字），由 mode 和 rdev 指定类型和设备号。
rename	将文件（old_dentry）从旧目录（old_dir）移动到新目录（new_dir），并赋予新名称（new_dentry）。可能涉及跨目录操作。
permission	检查对 inode 执行特定操作（由 mask 指定，如 MAY_READ, MAY_WRITE, MAY_EXEC）的权限。在路径遍历和文件访问时被 VFS 调用。需要支持 RCU-walk 模式。
setattr	修改 inode 的属性（如 i_mode, i_uid, i_gid, i_size, 时间戳等）。由 chmod, chown, truncate, utime 等系统调用触发。
getattr	获取 inode 的属性，填充 kstat 结构，用于 stat(2) 系统调用。需要处理 idmapped 挂载。
readlink	读取符号链接 inode 指向的目标路径。
follow_link	在路径解析过程中处理符号链接（由 VFS 调用）。

3.4 文件操作 (file_operations, i_fop)

i_fop 字段指向的 file_operations 结构定义了对打开的文件（由 struct file 对象表示）进行操作的方法。当一个文件被打开时，VFS 会将 inode->i_fop 的值复制到新创建的 struct file 对象的 f_op 字段中。这意味着后续对该打开文件的所有操作（如读、写）都将通过 file->f_op 指向的函数来执行。这些操作将在第 5 节详细讨论。

inode 作为文件系统对象元数据的核心载体，其重要性不言而喻。它不仅存储了对象的静态属性（如权限、大小、时间戳），还通过 i_op 和 i_fop 指针动态地链接到实现具体操作的函数集。i_mapping 字段则将其与 VFS 的缓存和 I/O 子系统（address_space）联系起来。理解 inode 如何聚合这些信息并提供操作接口，是理解 VFS 如何管理文件和目录的基础。它体现了 VFS 将不同文件系统的对象抽象为统一模型的核心思想，同时通过操作表将通用接口映射到特定实现。

4. dentry 对象：路径名组件的表示

dentry（目录项）对象在 VFS 中扮演着连接文件名（路径组件）和 inode 的桥梁角色。当我们在文件系统中导航或访问一个文件时，例如 /usr/bin/vi，路径中的每一个组成部分（usr、bin、vi）在 VFS 内部都可能由一个 dentry 对象来表示。dentry 的核心功能是将一个特定的名称与其在父目录中对应的 inode 关联起来。

dentry 的一个显著特点是它仅存在于内存中。它主要是为了性能优化而设计的，特别是为了加速路径名查找（pathname lookup）过程。VFS 将最近访问过的路径组件及其对应的 inode 关系缓存起来，形成目录项缓存（dentry cache，简称 dcache）。当再次需要解析相同路径时，VFS 可以直接从 dcache 中快速获取信息，避免了昂贵的磁盘访问或对底层文件系统的重复查询。底层文件系统本身以其特有的格式存储目录信息（文件名和 inode 号的对应关系），VFS 在需要时读取这些信息来构建内存中的 dentry 对象。

4.1 dentry 在路径查找和 dcache 中的作用

路径名解析是 VFS 的核心功能之一，而 dcache 和 dentry 对象在其中扮演着中心角色。当系统调用（如 open, stat）传入一个路径名时，VFS 的路径查找逻辑（主要在 fs/namei.c 中实现，如 link_path_walk 函数）会启动：

1. 确定起点：根据路径是绝对路径（以 / 开头）还是相对路径，确定查找的起始 dentry。绝对路径从当前进程的根目录 dentry 开始，相对路径从当前工作目录 dentry 开始（这些信息存储在进程的 task_struct 中）。对于 *at() 系列系统调用，起点可以是用户指定的目录文件描述符对应的 dentry。
2. 逐级解析：VFS 逐个处理路径名中的组件（由 / 分隔的部分）。
3. dcache 查询：对于每个路径组件，VFS 会使用该组件的名称和其父目录的 dentry 作为键，在 dcache 的哈希表 (dentry_hashtable) 中进行查找。哈希计算通常由 dentry_operations->d_hash（如果文件系统提供）或 VFS 默认哈希函数完成。
4. 缓存命中 (Cache Hit)：如果在 dcache 中找到了匹配的 dentry 对象：
   • 有效性验证：对于某些文件系统（特别是网络文件系统），VFS 可能需要调用 dentry->d_op->d_revalidate 来确认缓存的 dentry 信息仍然有效。如果无效，可能需要重新查找。
   • 获取 Inode：从找到的 dentry 中获取指向 inode 的指针 (dentry->d_inode)。
   • 权限检查：VFS 会调用 inode->i_op->permission 来检查当前进程是否有权访问或遍历该目录/文件。
   • 处理特殊情况：VFS 会检查是否遇到挂载点（mount point）或符号链接，并进行相应的处理（如切换 vfsmount 或解析链接目标）。
   • 进入下一级：将当前找到的 dentry 作为下一轮查找的父 dentry，继续解析路径的下一个组件。
5. 缓存未命中 (Cache Miss)：如果在 dcache 中没有找到匹配的 dentry：
   • 调用 lookup：VFS 必须向底层文件系统查询。它会调用父目录 inode 的 lookup 操作，即 parent_inode->i_op->lookup(parent_inode, target_dentry)，其中 target_dentry 包含了要查找的名称。
   • 文件系统查找：具体的文件系统实现（如 ext4, XFS）会根据其自身的目录结构（如目录文件、B+树等）在存储介质上查找该名称对应的 inode 号。
   • 创建新 Dentry：如果文件系统成功找到了对应的 inode：
     • VFS（或文件系统）会通过 iget() 等函数获取该 inode 的内存对象 struct inode。
     • VFS 会分配一个新的 dentry 对象。
     • 调用 d_add() 或 d_instantiate() 将新的 dentry 与找到的 inode 关联起来。
     • 将这个新的 dentry 添加到 dcache 的哈希表和父 dentry 的子节点列表中，以便后续查找可以命中缓存。
     • 然后，流程回到缓存命中的步骤继续处理。
   • 创建负 Dentry (Negative Dentry)：如果文件系统确认该名称在父目录下不存在：
     • VFS 可能会创建一个“负 dentry”，即一个 d_inode 指针为 NULL 的 dentry 对象。
     • 这个负 dentry 也会被添加到 dcache 中。
     • 这样做的目的是缓存“不存在”这一查找结果，使得后续对同一不存在路径的查找也能快速失败，而无需再次查询底层文件系统。
     • 路径查找过程因此失败。
6. 完成解析：重复上述步骤，直到路径的所有组件都被成功解析。最终，路径查找返回目标文件或目录对应的 dentry 对象（以及其所在的 vfsmount 对象，封装在 struct path 中）。

4.2 dentry 的关键字段

struct dentry 结构包含以下关键字段，用于实现其在路径查找和缓存中的功能：

字段名	类型	描述
d_name	struct qstr	存储目录项的名称（路径组件）。qstr 结构包含名称字符串本身 (name)、长度 (len) 和预计算的哈希值 (hash)。
d_inode	struct inode *	指向该目录项关联的 inode 对象。对于负 dentry，此字段为 NULL。只要 dentry 的引用计数 (d_lockref) 大于 0，非 NULL 的 d_inode 指针就不会改变。
d_parent	struct dentry *	指向父目录的 dentry 对象。形成目录树结构，允许向上遍历（例如处理 ..）。
d_op	const struct dentry_operations *	指向 dentry 操作表的指针。允许文件系统提供特定的 dentry 处理函数（如 d_revalidate, d_hash, d_compare）。
d_sb	struct super_block *	指向该 dentry 所属文件系统的 super_block 对象。
d_lockref	struct lockref	一个优化的结构，结合了自旋锁 (d_lock) 和引用计数 (d_count)。保护 dentry 的状态，防止在被使用时被意外释放或修改（如重命名）。
d_flags	unsigned int	Dentry 标志。例如 DCACHE_OP_REVALIDATE 表示需要调用 d_revalidate，DCACHE_MANAGE_TRANSIT 用于特殊挂载点处理（如 autofs）。
d_lru	struct list_head	用于将未使用的（unused）和负的（negative）dentry 连接到 LRU (Least Recently Used) 链表中，以便在内存压力下进行回收。
d_child / d_subdirs	struct list_head / struct hlist_node	用于将 dentry 连接到其父 dentry 的子链表（通常是哈希链表）或兄弟链表中。d_subdirs 主要用于父指向子的链接。

4.3 Dentry 状态和缓存管理

内存中的 dentry 对象可以处于以下几种状态：

• Used（使用中）：d_inode 指向一个有效的 inode，并且其引用计数 d_count（通过 d_lockref 管理）大于 0。这表示该 dentry 正被 VFS 的某个部分（如一个打开的文件 struct file，或路径查找过程中的临时引用）所使用。使用中的 dentry 不能被丢弃。它们通常也链接在对应 inode 的 i_dentry 链表上。
• Unused（未使用）：d_inode 指向一个有效的 inode，但 d_count 为 0。这表示 VFS 当前没有活动引用指向这个 dentry，但它仍然代表一个有效的文件系统对象。未使用的 dentry 会被保留在 dcache 的 LRU 链表 (d_lru) 中，以备将来快速查找。如果系统需要回收内存，这些 dentry 是优先被回收的对象。
• Negative（负）：d_inode 为 NULL。这表示该 dentry 对应的路径名在被查找时不存在，或者它之前关联的 inode 已经被删除了。负 dentry 同样被保留在 dcache 的 LRU 链表中，用于加速对无效路径的重复查找。它们也可以在内存压力下被回收。

dcache 的管理（包括添加、查找、删除和回收 dentry）是 VFS 性能的关键。LRU 链表 (d_lru) 使得内核可以有效地选择最旧、最不常用的未使用或负 dentry 进行回收。哈希表 (dentry_hashtable) 则保证了通过名称进行的查找操作能够高效完成。

4.4 dentry_operations 结构 (d_op)

与 inode 和 super_block 类似，dentry 也有一个可选的操作表 dentry_operations，通过 d_op 字段引用。这允许文件系统根据需要定制 dentry 的行为。

关键的 dentry_operations 方法包括：

方法名	描述
d_revalidate	检查缓存的 dentry 是否仍然有效。VFS 在使用 dcache 中的条目之前（特别是在查找过程中）可能会调用此函数，尤其对于网络文件系统或需要确保最新状态的情况。文件系统需要返回该 dentry 是否有效。此操作现在可能需要在 RCU-walk 模式下执行，如果文件系统不支持，应返回 -ECHILD。
d_hash	计算 dentry 名称的哈希值，用于将其放入 dcache 哈希表。文件系统可以提供自定义的哈希算法。其调用约定和锁规则已为支持 RCU-walk 而改变。
d_compare	比较两个文件名。VFS 默认使用区分大小写的字节比较。文件系统（如 VFAT）可以提供自定义的比较函数（例如，不区分大小写）。其调用约定和锁规则也已为支持 RCU-walk 而改变。
d_delete	当 dentry 的引用计数 d_count 降至 0 时调用。文件系统可以在此执行清理操作。
d_release	当 dentry 对象即将被释放（从内存中删除）时调用。
d_iput	当 dentry 与其关联的 inode 解除绑定时（例如，文件被删除 unlink）调用。默认情况下，VFS 会调用 iput() 来减少 inode 的引用计数。如果文件系统覆盖此函数，它必须确保最终也调用 iput() 或等效操作。
d_manage	如果 dentry 设置了 DCACHE_MANAGE_TRANSIT 标志，VFS 在尝试通过此 dentry 穿越到一个挂载点之前会调用此函数。主要用于 autofs 等文件系统，以处理卸载过程中的竞态条件或有选择地允许某些进程穿越挂载点。

dcache 对 VFS 性能至关重要，但它也带来了并发控制的挑战，尤其是在多核处理器系统上。最初，dcache 的操作受到一个全局锁 (dcache_lock) 的保护，这在高并发场景下成为了严重的性能瓶颈。为了提高可伸缩性，内核开发者进行了一系列重要的改进：首先引入了更细粒度的锁，例如每个 dentry 上的 d_lockref 结构，它结合了自旋锁和引用计数。然后，进一步发展出基于 RCU（Read-Copy-Update）的路径查找机制，称为“RCU-walk”。RCU-walk 的目标是允许路径查找操作在大多数情况下以只读方式进行，无需获取锁或修改 dentry 结构（如增加引用计数），从而显著减少锁竞争。这需要 dentry 操作（如 d_hash, d_compare, d_revalidate）和 inode 生命周期管理（需要 RCU 安全的释放）进行相应的调整，并引入了如 seqlock 等机制来处理 RCU 读取期间发生的并发修改。这种演进清晰地表明，VFS 的设计在不断地平衡抽象、性能和可伸缩性这几个关键因素。

5. file 对象：打开文件实例的表示

在 VFS 中，struct file 对象代表一个由进程打开的文件实例。与 inode 对象（代表文件本身及其持久元数据）不同，file 对象是临时的，并且仅存在于内存中。它封装了某个特定进程与某个特定文件交互的上下文信息。

当一个进程成功调用 open(2) 系统调用打开一个文件时，内核就会创建一个新的 struct file 对象。这个对象包含了这次“打开”会话所需的状态，例如当前读写位置（文件偏移量）、打开时指定的标志（如只读、非阻塞）以及访问模式。

同一个 inode（代表磁盘上的同一个文件）可以同时被多个 struct file 对象关联。这种情况发生在：

• 同一个进程多次打开同一个文件。
• 不同的进程打开了同一个文件。
• 一个进程通过 dup(2) 或 fork(2) 复制了文件描述符。

在这种情况下，每个打开实例（或文件描述符）都对应一个独立的 struct file 对象，但它们都指向同一个 inode 对象。这意味着它们共享文件的元数据和内容，但各自维护独立的打开状态（如文件指针位置 f_pos，除非文件以 O_APPEND 方式打开）。

5.1 file 对象与进程文件描述符的关系

struct file 对象与用户空间的文件描述符 (file descriptor, fd) 紧密相关。文件描述符是进程用来指代其打开文件的一个小的非负整数。它们之间的关系如下：

1. 进程文件描述符表：每个进程都有一个文件描述符表（通常在 task_struct->files->fdt 中实现，fdt 是 struct fdtable）。这个表是一个数组（或类似结构），其索引就是文件描述符。
2. 打开文件：当 open() 系统调用成功时，内核不仅创建了一个 struct file 对象，还会在调用进程的文件描述符表中找到一个未使用的最小索引（即文件描述符），并将该表项指向新创建的 struct file 对象。
3. 后续操作：当进程后续使用该文件描述符进行系统调用（如 read(fd,...)、write(fd,...)、lseek(fd,...)、close(fd)）时，内核会使用这个 fd 作为索引，在其文件描述符表中查找对应的 struct file 指针。
4. 关闭文件：当进程调用 close(fd) 时，内核会清除文件描述符表中的对应条目，并减少 struct file 对象的引用计数 (f_count)。当 f_count 降为 0 时（表示这是最后一个指向该 struct file 的引用），内核会调用 file->f_op->release 方法，并最终释放 struct file 对象本身。

因此，struct file 是文件描述符在内核中的实际对应物，是 VFS 对打开文件进行操作的句柄。

5.2 file 的关键字段

struct file 结构包含以下关键字段：

字段名	类型	描述
f_path	struct path	包含指向文件 dentry 和挂载点 vfsmount 的指针。struct path 封装了文件在 VFS 命名空间中的位置。可以通过 f_path.dentry 访问 dentry，进而获取文件名 (f_path.dentry->d_name.name) 或使用 d_path() 生成完整路径。
f_inode	struct inode *	指向与此打开文件关联的 inode 对象。这是从 f_path.dentry->d_inode 缓存的指针，提供了对文件元数据的快速访问。
f_op	const struct file_operations *	指向文件操作表的指针。定义了可以在这个打开的文件上执行的操作，如 read, write, llseek, mmap, ioctl, fsync, release 等。
f_pos	loff_t	当前文件读写位置（偏移量）。由 read, write, llseek 等操作更新。驱动程序不应直接修改此字段，而应使用传入操作函数的偏移量指针。该字段受 f_pos_lock 保护。
f_mode	fmode_t	文件的访问模式，包含 FMODE_READ 和 FMODE_WRITE 等位。表示文件是以读、写还是读写模式打开的。VFS 在调用 read/write 操作前会检查此模式。
f_flags	unsigned int	打开文件时指定的标志（通过 open() 的 flags 参数传入），如 O_APPEND, O_NONBLOCK, O_RDONLY, O_SYNC 等。驱动程序可能需要检查某些标志（如 O_NONBLOCK）来调整其行为。
f_count	atomic_long_t	struct file 对象的引用计数。每次文件描述符被复制（如 dup, fork）时增加，每次 close 时减少。当计数降为 0 时，对象被释放。
private_data	void *	一个供文件系统或设备驱动程序使用的私有数据指针。通常在 f_op->open 方法中设置，用于存储与此特定打开实例相关的状态信息。必须在 f_op->release 方法中释放其指向的资源（如果已分配）。
f_mapping	struct address_space *	指向 f_inode->i_mapping 的指针。提供了对管理文件页缓存的 address_space 对象的便捷访问。
f_cred	const struct cred *	打开此文件的进程的凭证（credentials）。
f_owner	struct fown_struct	用于信号驱动 I/O (asynchronous I/O notification)，记录希望接收 I/O 事件信号的进程或进程组。

5.3 file_operations 结构 (f_op) 的初始化与使用

f_op 字段是 struct file 中至关重要的部分，它定义了对这个打开的文件实例可以执行哪些操作以及如何执行。

• 初始化：在 open() 系统调用的后期阶段，当 VFS 已经通过路径查找找到了目标 inode 并分配了 struct file 对象后，它会将 inode->i_fop（指向特定文件系统为该类型 inode 定义的文件操作表）的值赋给 file->f_op。
• 调用 open 方法：紧接着，VFS 会调用刚刚设置的 file->f_op 中的 open 方法（如果该方法存在的话）：file->f_op->open(inode, file)。这为底层文件系统或设备驱动提供了一个机会，来执行特定于此次打开操作的初始化步骤，例如分配和设置 file->private_data。
• 分发后续操作：对于后续的系统调用，如 read, write, llseek, ioctl, mmap, fsync, close 等，VFS 会通过文件描述符找到对应的 struct file 对象，然后查找 file->f_op 指向的操作表，并调用其中相应的函数指针来执行请求的操作。例如，当调用 read(fd,...) 时，内核最终会执行 file->f_op->read(...) 或 file->f_op->read_iter(...)。

file_operations 结构中包含多种操作，以下是一些常见的：

方法名	描述
llseek	实现 lseek(2) 系统调用，改变文件当前的读写偏移量 (f_pos)。generic_file_llseek 是一个常用的通用实现。
read / read_iter	实现 read(2) 系统调用，从文件的当前偏移量 f_pos 处读取数据到用户提供的缓冲区。read_iter 是较新的基于 kiocb 和 iovec 的接口。通用实现如 generic_file_aio_read 或 generic_file_read_iter 通常处理页缓存交互。
write / write_iter	实现 write(2) 系统调用，将用户缓冲区的数据写入文件的当前偏移量 f_pos 处。write_iter 是较新的接口。通用实现如 generic_file_aio_write 或 generic_file_write_iter 通常处理页缓存交互。
mmap	实现 mmap(2) 系统调用，将文件内容映射到进程的地址空间。generic_file_mmap 是常用的通用实现。
open	在文件成功打开后，由 VFS 调用，允许文件系统或驱动程序执行额外的初始化。
release (或 flush)	在文件的最后一个引用被关闭时（即 f_count 降为 0 之后）调用。用于执行清理工作，例如释放 private_data 指向的内存。flush 在每个 close() 时都可能被调用，而 release 仅在最后一个引用关闭时调用。
fsync	实现 fsync(2) 或 fdatasync(2) 系统调用，将文件的脏数据和/或元数据强制写回持久存储。
ioctl / unlocked_ioctl / compat_ioctl	实现 ioctl(2) 系统调用，提供了一种执行设备或文件系统特定命令的机制。unlocked_ioctl 是不使用 BKL (Big Kernel Lock) 的版本，compat_ioctl 用于处理 32 位进程在 64 位内核上的 ioctl 调用。

struct file 对象体现了 VFS 如何为每个打开的文件实例维护一个独立的上下文。它与代表持久文件元数据的 inode 分离，存储了与当前打开会话相关的状态（如 f_pos）。通过从 inode->i_fop 继承而来的 f_op 指针，它确保了对该打开文件的操作能够正确地分派到所属文件系统或设备驱动程序的实现代码。这种设计既保证了操作的正确性，也维持了 VFS 的通用性。

6. file_system_type 对象：文件系统注册与管理

file_system_type 结构是 VFS 用来识别和管理系统中所有已知文件系统类型的核心机制。它本身不代表一个已挂载的文件系统实例（那是 super_block 的职责），而是描述了一类文件系统（例如，“ext4”、“proc”、“nfs”）的属性和入口点。

每个希望被 Linux 内核支持的文件系统，无论是内置的还是作为可加载模块实现的，都必须定义并注册一个 file_system_type 结构。这个注册过程使得 VFS 知道该文件系统的存在，并能够在用户请求挂载该类型的文件系统时调用其特定的处理函数。

6.1 file_system_type 的关键字段

struct file_system_type 包含以下关键字段：

字段名	类型	描述
name	const char *	文件系统类型的唯一名称字符串。这个名称用于 mount -t <name> 命令，以及在 /proc/filesystems 中列出已注册的文件系统。
mount	struct dentry * (*)(struct file_system_type *, int, const char *, void *)	函数指针，指向该文件系统的挂载函数。当 VFS 需要挂载此类型的文件系统实例时调用此函数。它负责创建或获取 super_block 并返回根 dentry。
kill_sb	void (*)(struct super_block *)	函数指针，指向该文件系统的卸载（杀死超级块）函数。当 VFS 需要卸载此文件系统的一个实例时调用此函数，负责清理和释放 super_block 相关资源。
fs_flags	int	描述文件系统类型属性的标志。例如：FS_REQUIRES_DEV 表示该文件系统需要一个块设备支持；FS_USERNS_MOUNT 表示允许在用户命名空间内挂载；FS_NO_DCACHE 可能表示不使用 dentry 缓存。
owner	struct module *	指向拥有此文件系统类型的内核模块。对于内置文件系统，通常为 NULL；对于模块，应设为 THIS_MODULE。VFS 使用它来管理模块的引用计数，防止模块在被使用时被卸载。
next	struct file_system_type *	指向内核中下一个已注册文件系统类型的指针，形成一个全局链表。文件系统实现应将其初始化为 NULL。
fs_supers	struct list_head	一个链表头，用于链接所有属于此文件系统类型的活动 super_block 实例。
init_fs_context	int (*)(struct fs_context *)	（现代挂载 API）函数指针，用于初始化文件系统特定的挂载上下文 (fs_context)。
parameters	const struct fs_parameter_spec *	（现代挂载 API）指向描述该文件系统支持的挂载参数的结构。用于参数验证和查询。

6.2 文件系统注册与注销

文件系统类型通过以下两个 VFS 函数进行注册和注销：

• register_filesystem(struct file_system_type *fs)：此函数将 fs 指向的 file_system_type 结构添加到内核维护的全局已知文件系统类型链表中。注册成功后，该文件系统类型就可以通过 mount 命令等方式被挂载。对于实现为内核模块的文件系统，此函数通常在其模块初始化函数（init_module）中调用。
• unregister_filesystem(struct file_system_type *fs)：此函数从内核的全局链表中移除指定的 file_system_type 结构。这通常在文件系统模块的退出函数（cleanup_module）中调用，以确保在模块卸载前，该文件系统类型不再可用。

6.3 mount 和 kill_sb 操作的角色

mount 和 kill_sb 是 file_system_type 结构中定义的两个核心操作，它们构成了 VFS 与具体文件系统类型交互的主要入口点，分别负责文件系统实例的创建和销毁。

• mount 操作：

  • 触发时机：当用户执行 mount 系统调用，指定要挂载的文件系统类型时，VFS 找到对应的 file_system_type 结构，并调用其 mount 成员指向的函数。
  • 输入参数：mount 函数接收文件系统类型 (fs_type)、挂载标志 (flags)、设备名称 (dev_name) 和特定于文件系统的选项数据 (data) 作为参数。
  • 核心任务：其主要职责是为这个新的挂载实例创建或获取一个 super_block 对象。这通常涉及：
    • 对于块设备文件系统，打开指定的设备 dev_name。
    • 读取设备上的物理超级块信息（如果存在）。
    • 分配 struct super_block 结构。
    • 调用 fill_super 回调函数来填充 super_block 的详细信息，设置 s_op，并创建根 inode 和根 dentry (s_root)。
  • 返回值：mount 函数必须返回指向新挂载文件系统根目录的 dentry 对象。如果失败，则返回错误指针（如 ERR_PTR(-ENOMEM)）。VFS 会将返回的 dentry 与用户指定的挂载点目录关联起来。
  • 子树挂载：mount 操作不一定总是创建一个全新的 super_block。在某些情况下（例如绑定挂载或 NFS 子目录挂载），它可以返回一个已存在文件系统的子树的根 dentry。

• kill_sb 操作：

  • 触发时机：当用户执行 umount 系统调用来卸载一个文件系统实例时，VFS 会调用该文件系统类型对应的 file_system_type 结构中的 kill_sb 成员指向的函数。
  • 输入参数：kill_sb 函数接收一个指向要被销毁的 super_block 对象的指针。
  • 核心任务：其主要职责是执行所有必要的清理工作，并释放与该 super_block 实例相关的资源。这包括：
    • 调用 super_block->s_op->put_super 方法来释放文件系统特定的资源（例如，s_fs_info 指向的内存）。
    • 释放 VFS 为 super_block 分配的其他资源。
    • 对于不同类型的文件系统，通常会调用相应的 VFS 辅助函数来完成大部分清理工作，如 kill_block_super（用于块设备文件系统）、kill_anon_super 或 kill_litter_super（用于虚拟或内存文件系统）。

6.4 现代挂载 API 集成

如前所述，现代内核版本引入了基于 fs_context 的挂载 API，以提供更灵活和结构化的挂载选项处理。file_system_type 结构通过新增的 init_fs_context 和 parameters 字段来支持这个新 API：

• init_fs_context：当 VFS 开始处理挂载或重新配置请求时，会调用此函数来创建一个特定于文件系统的上下文 (fs_context)。文件系统可以在此函数中设置上下文的操作 (fc->ops) 和私有数据区域 (fc->fs_private)，用于后续解析和存储挂载参数。
• parameters：此字段指向一个描述符数组，定义了该文件系统可以接受的参数名称、类型（如布尔、字符串、整数）以及可能的取值范围或枚举值。这使得 VFS 和用户空间工具（如 mount 命令或 fsinfo() 系统调用）能够验证和理解可用的挂载选项。

file_system_type 结构在 VFS 中扮演着“文件系统工厂”和注册表的角色。它不直接管理活动的挂载实例，而是提供了 VFS 创建（通过 mount）和销毁（通过 kill_sb）这些实例（即 super_block 对象）所需的方法和元信息。通过 register_filesystem 和 unregister_filesystem，内核可以动态地管理其支持的文件系统类型集合。owner 字段确保了模块化文件系统的代码在其实例仍在使用时不会被卸载。现代挂载 API 的引入进一步增强了 file_system_type 在挂载过程中的作用，使其能够更精细地控制参数处理和上下文初始化。

7. address_space 对象：页缓存与 I/O 管理

address_space 结构是 VFS 中负责管理文件数据缓存和 I/O 操作的核心组件。它的主要目的是在文件的逻辑视图（按字节或页偏移量访问）和其在物理内存中的缓存（页缓存）以及最终的持久化存储（后备存储，backing store，通常是磁盘块）之间建立联系并进行管理。

页缓存（page cache）是 Linux 内核用来缓存文件数据以减少磁盘 I/O 的主要机制。当应用程序读取文件时，内核首先检查所需数据是否已在页缓存中；如果是（缓存命中），则直接从内存中读取，避免了缓慢的磁盘访问。当应用程序写入文件时，数据通常先被写入页缓存中的相应页面，这些页面被标记为“脏”（dirty），然后在稍后的某个时间点由内核的写回（writeback）机制异步地写回到磁盘。address_space 对象就是管理特定文件在页缓存中的页面集合以及这些页面与后备存储之间数据传输的实体。

7.1 address_space 与 inode 及内存管理的关系

address_space 对象与 inode 和内核内存管理子系统紧密相连：

• 与 inode 的关联：通常，每个需要缓存数据的 inode（主要是普通文件和目录，有时也包括块设备）都有一个与之关联的 address_space 对象。这个关联通过 inode 结构中的 i_mapping 字段实现，该字段指向对应的 address_space 对象。反过来，address_space 结构中的 host 字段也指向其所属的 inode（或块设备）。
• 页缓存管理：address_space 对象的核心功能是管理属于其 host inode 的页面在全局页缓存中的存在。它使用一个基数树（radix tree）或 XArray（i_pages 字段）来有效地索引这些页面，允许通过文件内的页偏移量快速查找对应的 struct page。
• 内存分配与状态：当需要为文件缓存新的页面时（例如，读操作发生缓存未命中，或写操作需要新页面），address_space 会与内存管理子系统交互来分配物理页面（使用 gfp_mask 字段指定的分配标志）。它也负责跟踪这些页面的状态，例如是否脏 (Dirty), 是否正在写回 (Writeback), 是否被引用 (Referenced) 等。
• 内存映射 (mmap)：address_space 在处理文件的内存映射（mmap）时也扮演关键角色。i_mmap 字段（一个红黑树）记录了所有将该文件映射到进程地址空间的虚拟内存区域（VMA）。i_mmap_writable 字段则跟踪有多少个共享的可写映射。这使得内核能够在页面被修改时（例如通过内存写入）或需要同步时（例如 msync()）有效地管理这些映射。
• 内核内存管理：address_space 结构甚至可以用于管理非文件相关的内核内存页面，例如通过匿名 inode (anon_inode) 来管理可移动的内核内存，以支持内存规整（compaction）。

7.2 address_space 的关键字段

struct address_space 包含以下关键字段：

字段名	类型	描述
host	struct inode * 或 struct block_device *	指向拥有此地址空间的对象（通常是 inode）。
i_pages	struct xarray	（较新内核）或 struct radix_tree_root page_tree （较旧内核）用于存储和查找属于此地址空间的缓存页面 (struct page) 的数据结构，通过页索引（文件内偏移量/PAGE_SIZE）进行映射。
a_ops	const struct address_space_operations *	指向地址空间操作表的指针。定义了与后备存储交互的方法。
nrpages	unsigned long	当前在此地址空间中缓存的总页面数。
gfp_mask	gfp_t	用于为此地址空间分配页面时的内存分配标志 (Get Free Page flags)。
i_mmap	struct rb_root_cached	跟踪将此地址空间映射到进程虚拟地址空间的 VMA (Virtual Memory Area) 的红黑树。
i_mmap_writable	atomic_t	共享可写映射的数量。
invalidate_lock	struct rw_semaphore	读写信号量，用于在页面失效（如截断 truncate）期间保护页缓存内容与文件系统块映射之间的一致性。
flags	unsigned long	地址空间的状态标志，例如 AS_EIO 表示发生了 I/O 错误。
writeback_index	pgoff_t	写回操作的起始页索引，用于跟踪写回进度。
wb_err	errseq_t	记录最近发生的写回错误。
i_private_data	void *	供 host 对象使用的私有数据指针。

7.3 address_space_operations 结构 (a_ops)

a_ops 字段指向的 address_space_operations 结构是 address_space 功能的核心，它定义了 VFS 如何通过页缓存与具体的后备存储（由 host inode 所属的文件系统或块设备驱动提供）进行交互。

以下是一些关键的 address_space_operations 方法：

方法名	描述
readpage / readfolio	从后备存储读取单个页（或 folio，一组物理连续的页）的数据到指定的 struct page（或 struct folio）中。当发生页缓存未命中时，由 VFS 的读路径调用。
readpages / readahead	从后备存储预读多个页/folio 到页缓存中，以期提高后续顺序读取的性能。
writepage / write_folio	将一个脏页/folio 从页缓存写回到后备存储。由内核的写回机制（如 flusher 线程）调用。可能返回特殊代码如 AOP_WRITEPAGE_ACTIVATE。
writepages	将地址空间中的多个脏页/folio 写回到后备存储。通常是写回机制的主要入口点。
write_begin / write_end	用于支持需要特殊准备和提交步骤的写操作（通常用于缓冲写和日志文件系统）。write_begin 在数据复制到页面之前调用（例如，分配日志空间），write_end 在数据复制之后调用（例如，提交日志事务）。
set_page_dirty	标记一个页缓存页面为脏。文件系统可以重载此函数以执行额外操作，例如将相关元数据（如 buffer heads）也标记为脏或启动日志记录。__set_page_dirty_nobuffers 是一个常用的 VFS 辅助函数。
bmap	将文件内的逻辑块号映射到后备存储上的物理块号。主要用于基于块的 I/O，在现代以页为中心的 VFS 中使用较少。
invalidatepage / invalidate_folio	当页面/folio 被截断或失效时调用，用于清理与该页面相关的元数据。
releasepage / release_folio	当页面/folio 最后一个引用被释放并且即将从页缓存中移除时调用。文件系统可以在此释放与页面相关的私有资源。
direct_IO	处理直接 I/O (Direct I/O, DIO) 请求，绕过页缓存直接在用户缓冲区和后备存储之间传输数据。
migratepage	（可选）支持将页面迁移到新的物理位置，用于内存规整和热插拔等场景。

address_space 及其操作表 a_ops 的设计是 VFS 实现其核心目标——提供统一接口同时保持高性能——的关键所在。它将文件数据的缓存管理（页缓存）与具体的 I/O 实现（文件系统或驱动程序）解耦。VFS 的通用代码（如 generic_file_read_iter, generic_file_write_iter）可以依赖 address_space 来处理页缓存的查找、分配和状态管理，而将与特定存储介质交互的复杂细节委托给 a_ops 中的函数。这种分层和委托机制使得 VFS 能够高效地利用系统内存进行缓存，同时支持各种不同的存储技术和文件系统结构。

8. VFS 结构在常见操作中的交互

前面几节分别介绍了 VFS 中的核心数据结构。然而，理解 VFS 的关键在于理解这些结构在实际文件系统操作中是如何协同工作的。本节将通过分析几个常见的操作流程——路径查找、文件打开、文件读取和文件写入——来阐述 super_block, inode, dentry, file, file_system_type, 和 address_space 之间的相互作用和数据流转。

8.1 路径查找流程 (Pathname Lookup)

路径查找是将用户提供的路径名（如 /home/user/data.txt）解析为对应的 inode 对象的过程，这是几乎所有基于路径的文件操作（如 open, stat, unlink）的第一步。

1. 起点确定：查找过程始于一个已知的 VFS 挂载点和目录项 (struct path，包含 vfsmount 和 dentry)。对于绝对路径，通常是当前进程的根目录 (task_struct->fs->root)；对于相对路径，是当前工作目录 (task_struct->fs->pwd)。*at() 系列系统调用允许指定一个文件描述符作为查找起点。
2. 组件迭代：VFS 的路径查找代码（如 link_path_walk）逐个解析路径名中的组件（由 / 分隔）。
3. dcache 查询：对于每个组件 name，VFS 在当前目录 dentry 的上下文中，使用 name 和父 dentry 在 dcache 哈希表中查找对应的子 dentry。
4. 缓存命中：
   • 如果找到匹配的 dentry：
     • 有效性检查：如果该 dentry 或其文件系统设置了需要重新验证的标志（如 DCACHE_OP_REVALIDATE），则调用 dentry->d_op->d_revalidate 确认缓存信息是否仍然有效。
     • 权限检查：获取 dentry->d_inode，然后调用 inode->i_op->permission 检查当前进程是否有遍历该目录或访问该文件的权限。
     • 特殊处理：检查此 dentry 是否是一个挂载点。如果是，需要根据挂载信息切换到新的 vfsmount 和目标文件系统的根 dentry。如果 dentry 对应的 inode 是一个符号链接，则需要读取链接目标路径 (inode->i_op->readlink 或 follow_link) 并重新开始解析目标路径。
     • 更新当前位置：如果一切正常，将当前找到的 dentry 设置为下一次迭代的父 dentry。
5. 缓存未命中：
   • 如果 dcache 中未找到匹配的 dentry：
     • 调用 lookup：VFS 调用当前目录 inode 的 lookup 操作：inode->i_op->lookup(inode, target_dentry)，其中 target_dentry 包含要查找的组件名称。
     • 文件系统查找：底层文件系统执行查找操作，在其内部数据结构（如目录文件、哈希树等）中搜索该名称。
     • 找到 inode：如果文件系统找到了对应的 inode，它会通过 iget() 等函数将其加载到内存中。VFS 随后会创建一个新的 dentry，通过 d_add() 将其与 inode 关联，并添加到 dcache 中。然后流程转到缓存命中的处理逻辑。
     • 未找到 (Negative)：如果文件系统确认名称不存在，VFS 可能会创建一个负 dentry（d_inode = NULL）并缓存起来。路径查找失败。
6. 循环与结束：重复步骤 3-5，直到路径的所有组件都被解析。最终，查找成功则返回包含目标 dentry 和 vfsmount 的 struct path；失败则返回错误。

交互总结 (路径查找)：此过程主要涉及 dentry（用于名称到 inode 的映射和缓存）、inode（提供 lookup 和 permission 操作）以及 dcache（哈希表和 LRU 列表）。super_block 间接参与（通过 dentry->d_sb 和 inode->i_sb）。

8.2 文件打开流程 (open() syscall)

打开文件是在路径查找成功的基础上，为进程创建一个可用的文件句柄（文件描述符）。

1. 路径查找：首先执行上一节描述的路径查找过程，找到目标文件或目录对应的 dentry 和 vfsmount (struct path)。如果路径不存在或权限不足，打开失败。
2. 分配文件描述符：内核在当前进程的文件描述符表中查找一个未使用的最小整数作为新的文件描述符 fd。
3. 分配 file 对象：内核分配一个新的 struct file 对象。
4. 初始化 file 对象：
   • file->f_path 设置为路径查找返回的 dentry 和 vfsmount。
   • file->f_inode 设置为 dentry->d_inode。
   • file->f_mode 和 file->f_flags 根据 open() 系统调用传入的标志（如 O_RDONLY, O_WRONLY, O_RDWR, O_APPEND, O_NONBLOCK）进行设置。
   • file->f_pos 初始化为 0。
   • 关键步骤：file->f_op 设置为 file->f_inode->i_fop。这将文件操作与底层文件系统或设备驱动程序提供的实现关联起来。
   • file->f_count 初始化为 1。
5. 调用 f_op->open：VFS 调用 file->f_op->open(inode, file)。这允许文件系统或设备驱动执行特定于打开操作的初始化，例如，分配和设置 file->private_data 以存储会话状态。
6. 关联文件描述符：将进程文件描述符表中的 fd 条目指向新创建并初始化的 struct file 对象。
7. 返回：将文件描述符 fd 返回给用户空间进程。

交互总结 (文件打开)：此过程建立在路径查找的基础上，核心是创建和初始化 struct file 对象。它连接了 dentry（路径）、inode（元数据和操作源 i_fop）和进程（文件描述符表）。file->f_op 的设置是 VFS 实现多态性的关键。

8.3 文件读取流程 (read() syscall)

当进程使用文件描述符读取数据时，VFS 会协调页缓存和底层文件系统来满足请求。

1. 获取 file 对象：内核使用进程提供的 fd 在其文件描述符表中查找对应的 struct file 指针。
2. 调用 VFS 读函数：内核调用 VFS 层的读函数，如 vfs_read()。
3. 权限和有效性检查：vfs_read 检查 file->f_mode 是否允许读操作，并进行其他有效性检查。
4. 调用 f_op->read：VFS 调用文件操作表中的读方法：file->f_op->read(...) 或 file->f_op->read_iter(...)。
5. 页缓存交互（通用实现）：许多文件系统使用 VFS 提供的通用读实现（如 generic_file_read_iter）。这个通用实现负责与页缓存交互：
   • 确定范围：根据 file->f_pos（当前文件偏移）和请求的 count（读取字节数），计算需要访问的页面范围（起始页索引和页数）。
   • 页面循环：遍历所需的每个页面：
     • 查找缓存页：使用 file->f_mapping（即 inode->i_mapping，指向 address_space 对象）和当前页索引，在页缓存（address_space->i_pages）中查找页面。通常使用 find_get_page() 或类似函数。
     • 缓存未命中：如果页面不在缓存中：
       • 分配一个新的 struct page。
       • 调用 address_space->a_ops->readpage(file, page)。这个 readpage 函数由底层文件系统提供，负责从后备存储（磁盘）读取数据填充到该页面中。
       • 将填充好的页面添加到 address_space->i_pages 中。
     • 缓存命中/填充后：
       • 内核现在拥有了包含所需数据的 struct page。
       • 将页面中的数据（从正确的页内偏移开始，最多读取请求的字节数或到页面末尾）复制到用户提供的缓冲区 buf 中。
       • 释放对 struct page 的引用。
   • 更新偏移量：更新 file->f_pos，增加实际读取的字节数。
6. 返回：将实际读取的字节数返回给用户空间。

交互总结 (文件读取)：读取操作的核心在于 file 对象（提供上下文 f_pos 和操作入口 f_op）、inode 对象（通过 i_mapping 提供 address_space）和 address_space 对象（管理页缓存 i_pages 并提供底层 I/O 操作 a_ops->readpage）。数据流通常是：后备存储 -> (a_ops->readpage) -> 页缓存 (struct page) -> VFS 读函数 -> 用户缓冲区。

8.4 文件写入流程 (write() syscall)

文件写入通常涉及将数据写入页缓存，并将页面标记为脏，实际的磁盘写入由后台机制完成。

1. 获取 file 对象：与读取类似，内核使用 fd 找到对应的 struct file。
2. 调用 VFS 写函数：调用 VFS 层的写函数，如 vfs_write()。
3. 权限和有效性检查：检查 file->f_mode 是否允许写操作，检查 O_APPEND 标志（如果设置，将 f_pos 移到文件末尾），检查文件是否不可变 (IS_IMMUTABLE(inode)) 等。
4. 调用 f_op->write：调用文件操作表中的写方法：file->f_op->write(...) 或 file->f_op->write_iter(...)。
5. 页缓存交互（通用实现）：通用写实现（如 generic_file_write_iter）处理页缓存：
   • 确定范围：根据 file->f_pos 和 count 计算目标页面范围。
   • 页面循环：遍历需要写入的每个页面：
     • 查找/分配缓存页：在 file->f_mapping->i_pages 中查找目标页面。如果页面不存在，则分配一个新的 struct page 并添加到 i_pages 中。如果写入不是覆盖整个页面，可能需要先调用 a_ops->readpage 将现有内容读入页面。
     • 准备写入（可选）：调用 address_space->a_ops->write_begin(file, page,...)。这允许日志文件系统等进行预处理，如分配日志空间。
     • 复制数据：将数据从用户缓冲区 buf 复制到内核 struct page 中的适当位置。
     • 提交写入（可选）：调用 address_space->a_ops->write_end(file, page,...)。用于完成写入操作，如提交日志事务。
     • 标记页面为脏：调用 set_page_dirty() 或文件系统特定的 a_ops->set_page_dirty(page)。这将页面标记为已修改，需要被写回。脏页面会被添加到 inode 和 super_block 的脏页链表中。
     • 释放页面引用。
   • 更新偏移量和 inode 大小：更新 file->f_pos。如果写入超出了当前文件大小，还需要更新 inode->i_size 并标记 inode 为脏 (mark_inode_dirty())。
6. 后台写回：标记为脏的页面不会立即写入磁盘。内核的写回机制（flusher 线程）会周期性地扫描脏页链表，或者在内存压力下、sync() 或 fsync() 调用时，调用 address_space->a_ops->writepage 或 writepages 将脏页数据写回到后备存储。
7. 返回：将成功写入的字节数返回给用户空间。

交互总结 (文件写入)：写入操作同样依赖 file (上下文, f_op), inode (i_mapping, i_size), 和 address_space (a_ops, i_pages)。数据流通常是：用户缓冲区 -> VFS 写函数 -> (a_ops->write_begin) -> 页缓存 (struct page) -> (a_ops->write_end, set_page_dirty)。实际的磁盘写入通过后台调用 a_ops->writepage 完成。super_block 通过其脏页链表和写回控制间接参与。

这些操作流程清晰地展示了 VFS 如何通过其核心数据结构的协作，实现对不同文件系统的统一访问。路径查找依赖 dentry 和 inode->i_op->lookup。文件打开连接了路径查找结果、进程和 file 对象，并通过 inode->i_fop 设置了文件操作。读写操作则通过 file->f_op 分派，利用 address_space 和 a_ops 与页缓存及底层存储进行交互。这种分层和面向对象的设计是 VFS 强大功能和灵的基础。

9. 文件系统常见问题分析

9.1 空文件和空目录的空间占用

理解文件和目录在磁盘上的空间占用情况，需要区分逻辑大小和实际磁盘使用量。

• 空文件：

  • 逻辑大小：一个空文件，顾名思义，其内容为空，因此其逻辑大小（ls -l 显示的大小）为 0 字节。
  • 磁盘占用：尽管逻辑大小为 0，但文件系统仍然需要存储该文件的元数据。这包括：
    • Inode：每个文件都需要一个 inode 来存储其属性（权限、所有者、时间戳、大小等）。Inode 本身在磁盘上会占用固定大小的空间（例如，ext4 默认为 256 字节，XFS 也是类似大小）。
    • 目录项 (Dentry)：文件名和指向 inode 的指针需要存储在父目录的数据块中。目录项的大小取决于文件名长度和文件系统实现。
  • 数据块：一个真正的空文件（没有写入任何数据）通常不占用任何数据块。其 inode 中的数据块指针列表为空。
  • 文件系统差异：
    • Ext4：在创建文件系统时会预先分配 inode 表。这意味着即使文件系统是空的，inode 表本身也会占用一部分空间。此外，ext4 默认会为 root 用户保留 5% 的空间，这也会影响 df 报告的可用空间。
    • XFS：采用动态 inode 分配，只在需要时才分配 inode，因此在空文件系统或文件数量较少时，元数据开销可能比 ext4 小。
    • Inline Data：某些文件系统（如 XFS 和启用了 inline_data 特性的 ext4）可以将非常小的文件数据直接存储在 inode 结构本身占用的空间内，从而避免分配单独的数据块。在这种情况下，即使文件有少量内容，其占用的磁盘块数（du 命令所见的）也可能为 0。

• 空目录：

  • 逻辑大小：目录本质上是一个特殊的文件，其内容是目录项（文件名和对应 inode 号）的列表。一个“空”目录并非完全为空，它至少包含两个特殊的目录项：.（指向自身 inode）和 ..（指向父目录 inode）。因此，ls -l 显示的目录大小通常不是 0，而是表示存储这些基本条目所需的最小空间。这个大小通常是文件系统块大小的倍数（如 ext4 默认为 4096 字节），但也可能因文件系统而异（例如，XFS 上的空目录可能显示为很小的值，如 6 字节，因为它可能将少量目录项存储在 inode 内部）。
  • 磁盘占用：与文件类似，目录也需要一个 inode 来存储其元数据。目录的内容（目录项列表）存储在一个或多个数据块中。即使目录为空（只包含 . 和 ..），通常也至少需要分配一个数据块来存储这些条目（除非文件系统支持将极小的目录内容存储在 inode 内，如 XFS 的 shortform directories）。
  • 目录大小增长与收缩：在许多文件系统（特别是 ext2/3/4）中，当向目录添加文件时，目录的逻辑大小（ls -l）和占用的数据块（du）会增长以容纳新的目录项。然而，当从目录中删除文件时，目录项会被标记为未使用，但目录的逻辑大小和分配的数据块通常不会自动收缩。这可能导致一个逻辑上为空（除了 . 和 ..）的目录在 ls -l 中显示较大的尺寸，因为它反映了历史上存储过的最大条目数量所需的空间。XFS 等文件系统可能在目录项管理上有所不同。

总结来说，空文件逻辑大小为 0，但其元数据（inode 和目录项）会占用少量磁盘空间。空目录逻辑大小通常不为 0（至少包含 . 和 ..），并占用 inode 和至少一个数据块（除非有 inode 内存储优化）。文件系统的具体实现（如 inode 分配策略、保留空间、inline data、目录收缩行为）会影响空文件和空目录的实际磁盘空间占用。

9.2 软链接与硬链接的本质区别

软链接（Symbolic Link 或 Symlink）和硬链接（Hard Link）是在类 Unix 文件系统中创建文件别名的两种不同方式，它们在实现机制和行为上有本质的区别。

• 核心机制：

  • 硬链接 (Hard Link)：硬链接本质上是为同一个文件内容（由同一个 inode 代表）创建了另一个目录项 (dentry)。它直接将一个新的文件名关联到已存在的 inode 上。因此，一个文件可以有多个文件名（硬链接），它们都指向同一个 inode，共享相同的数据和元数据。可以认为，普通的文件名本身就是指向其 inode 的第一个硬链接。
  • 软链接 (Symbolic Link)：软链接是一个特殊类型的文件，它有自己的 inode。这个特殊文件的内容是它所指向的目标文件或目录的路径名字符串。它不直接指向 inode 或数据，而是指向另一个文件名。

• Inode 关系：

  • 硬链接：所有指向同一个文件的硬链接共享同一个 inode 号。它们在元数据层面是无法区分的，都是对同一份底层数据的平等引用。
  • 软链接：软链接本身是一个独立的文件，拥有自己的 inode 号，与目标文件的 inode 号不同。

• 对目标文件/目录的操作影响：

  • 硬链接：
    • 删除：删除一个硬链接（文件名）只是减少了 inode 的链接计数 (i_nlink)。文件的实际数据和 inode 只有在链接计数降为 0 时才会被系统回收。因此，删除原始文件名或其他硬链接不会影响通过其他硬链接访问文件内容。
    • 移动/重命名：移动或重命名一个硬链接不会影响其他硬链接，因为它们都直接指向 inode。
    • 修改内容：通过任何一个硬链接修改文件内容，所有其他硬链接都会看到这些更改，因为它们共享同一份数据。
  • 软链接：
    • 删除目标：如果删除了软链接所指向的目标文件或目录，软链接本身仍然存在，但会变成一个“悬空链接”（dangling link），访问它将导致“文件未找到”之类的错误。
    • 移动/重命名目标：如果移动或重命名了目标文件或目录，软链接（如果使用的是绝对路径或相对路径不再有效）也会失效。
    • 替换目标：如果在目标被删除后，创建一个同名的新文件或目录，原来的软链接现在会指向这个新创建的对象。
    • 删除软链接：删除软链接本身不会影响目标文件或目录。

• 限制：

  • 硬链接：
    • 不能跨文件系统创建。因为 inode 号只在单个文件系统内唯一。
    • 通常不允许为目录创建硬链接（除了系统自动创建的 . 和 ..）。这是为了防止在文件系统层级中产生循环。
  • 软链接：
    • 可以跨文件系统创建。
    • 可以指向目录。
    • 可以指向不存在的文件或目录。

• 其他区别：

  • 大小：硬链接的大小显示为目标文件的大小；软链接的大小通常是其存储的目标路径字符串的长度（以字节为单位）。
  • 权限：硬链接共享目标文件的权限（因为它们共享 inode）；软链接本身有自己的权限位（通常是 lrwxrwxrwx），但访问目标文件时最终受目标文件的权限限制。

总结来说，硬链接是同一文件内容的多个名字，共享 inode 和数据，不能跨文件系统，通常不能用于目录。软链接是一个指向路径名的独立文件，有自己的 inode，可以跨文件系统，可以指向目录，但如果目标路径失效则链接会断开。

10. 结论

本报告深入分析了 Linux 虚拟文件系统 (VFS) 层中的关键数据结构，包括 super_block、inode、dentry、file、file_system_type 以及 address_space 和 address_space_operations。通过对这些结构的目标、关键字段、操作方法及其在核心文件系统操作（如挂载、路径查找、文件打开、读写）中的角色的细致考察，并增加了对常见文件系统问题（如空文件/目录空间占用、软硬链接区别）的分析，可以得出以下结论：

1. VFS 的核心是抽象与统一：VFS 成功地在用户空间应用程序和多样化的底层文件系统实现之间建立了一个强大的抽象层。通过定义一套通用的对象模型（super_block, inode, dentry, file）和相应的操作接口（*_operations），VFS 使得应用程序可以用统一的方式（标准系统调用）访问任何类型的文件系统，同时也极大地简化了新文件系统的开发和集成。

2. 数据结构各司其职，紧密协作：

   • file_system_type 作为文件系统类型的注册入口和工厂，负责文件系统实例的创建 (mount) 和销毁 (kill_sb)。
   • super_block 代表一个已挂载的文件系统实例，是该实例在 VFS 中的根节点，持有全局信息和文件系统级操作 (s_op)。
   • inode 是文件系统对象的元数据核心，存储除名称外的所有属性，并提供针对对象本身 (i_op) 和打开后文件 (i_fop) 的操作接口。
   • dentry 连接文件名和 inode，并通过 dcache 机制极大地加速路径查找。
   • file 代表一个打开的文件实例，维护进程相关的状态（如文件指针 f_pos）并持有从 inode 继承的文件操作 (f_op)。
   • address_space 作为 inode 与内存管理之间的桥梁，负责管理页缓存中的文件数据，并通过 address_space_operations (a_ops) 处理与后备存储的 I/O 交互。

3. 操作流程体现结构交互：常见的文件系统操作清晰地展示了这些数据结构之间的依赖和数据流转。路径查找是 dentry 和 inode->i_op->lookup 的舞台。文件打开连接了路径查找结果、进程和 file 对象，关键在于通过 inode->i_fop 初始化 file->f_op。文件读写则通过 file->f_op 调用，经由 inode->i_mapping 指向的 address_space 与页缓存交互，最终依赖 address_space->a_ops 与底层存储通信。

4. 常见问题体现底层机制：对空文件/目录空间占用和软硬链接区别的分析进一步揭示了 VFS 和具体文件系统实现的细节。空对象的空间占用涉及 inode、目录项和数据块分配策略（包括 inline data 和预留空间）。软硬链接的区别根植于它们是指向 inode（硬链接）还是指向路径名（软链接），这直接决定了它们在文件删除、跨文件系统操作和目标类型上的不同行为。

5. 性能与可伸缩性的持续演进：虽然 VFS 的抽象带来了巨大的灵活性，但性能始终是关键考量。VFS 通过广泛使用缓存（dcache, page cache）来弥补抽象带来的开销。同时，随着硬件的发展（尤其是多核处理器），VFS 也在不断演进以应对新的挑战。dcache 锁机制从全局锁到 RCU-walk 的演变，以及现代挂载 API 的引入，都体现了 VFS 在追求更高性能和更好可伸缩性方面的持续努力。

总之，Linux VFS 通过其精心设计的核心数据结构及其操作接口，构建了一个强大、灵活且高效的文件系统框架。理解这些数据结构及其相互作用，以及它们如何影响常见的文件系统行为，对于深入掌握 Linux 内核的文件系统子系统、进行文件系统开发或进行系统性能调优都至关重要。它们共同构成了 Linux 处理文件和存储的基础设施，是 Linux 操作系统成功的关键因素之一。