4. 路径查找与dentry缓存：路径解析过程（path_walk）、dentry缓存（dcache）的查找与哈希、LRU回收机制
路径查找是VFS层最频繁的操作之一。每次用户态程序通过open()、stat()、execve()等系统调用访问文件时，内核都需要将路径字符串（如/home/user/docs/report.txt）逐分量解析为对应的目录项和索引节点。这个过程称为路径解析（path_walk），其性能直接决定了文件系统操作的延迟。
为了加速路径解析，内核引入了dentry缓存（dcache），将已解析的路径分量与对应的dentry对象关联起来。dcache通过哈希表实现快速查找，并通过LRU链表管理缓存项的回收。本章将深入剖析这三者的协同工作原理。
4.1 路径解析过程（path_walk）
路径解析的核心任务是将用户提供的路径字符串，从根目录或当前工作目录开始，逐级向下查找，直到找到目标文件或目录对应的dentry和inode。整个过程由path_walk()函数（或更现代的path_lookupat()）驱动。
4.1.1 路径解析的两种模式
| 模式 | 起始点 | 典型场景 | 性能特点 |
|---|---|---|---|
| 绝对路径 | 根目录（/） |
/etc/passwd、/usr/bin/gcc |
每次从根开始，dcache命中率取决于路径深度 |
| 相对路径 | 当前工作目录（cwd） | ./docs/report.txt、../src/main.c |
通常路径较短，dcache命中率较高 |
4.1.2 逐分量解析流程
路径解析采用逐分量（component-by-component）的方式，每个分量对应路径中的一个目录名或文件名。以/home/user/docs/report.txt为例，解析过程如下：
- 起始点确定：绝对路径从根dentry（
/.）开始；相对路径从当前工作目录的dentry开始。 - 分量提取：从路径字符串中提取第一个分量
home。 - dcache查找：在当前目录的dentry子目录哈希表中查找名为
home的子dentry。 - 缓存命中：若dcache命中，直接获取对应的dentry和inode，跳至步骤6。
- 缓存未命中：调用底层文件系统的
lookup()回调，从磁盘读取目录项，创建新的dentry并插入dcache。 - 权限检查：检查当前进程是否对该目录有执行（x）权限。
- 迭代：将当前dentry更新为
home的dentry，提取下一个分量user，重复步骤3-6。 - 终止：处理完最后一个分量
report.txt后，返回目标dentry和inode。
4.1.3 路径解析的SVG流程图
4.2 dentry缓存（dcache）的查找与哈希
dcache是VFS层最重要的缓存之一，它将文件路径中的每个分量（目录名或文件名）映射到对应的dentry对象。dcache的核心数据结构是一个全局哈希表，用于快速定位dentry。
4.2.1 dcache的哈希表结构
dcache使用dentry_hashtable作为主索引，哈希键由父dentry指针和分量名称的哈希值共同计算得出。每个哈希桶是一个链表，存储所有哈希值相同的dentry。
| 哈希键组成 | 说明 | 作用 |
|---|---|---|
parent（父dentry指针） |
指向当前dentry的父目录dentry | 确保不同目录下的同名文件不会冲突 |
name（名称哈希值） |
对分量名称字符串计算哈希 | 快速定位到具体的文件名或目录名 |
hash（组合哈希值） |
hash = parent ^ name_hash |
最终用于索引哈希表 |
4.2.2 dcache查找流程
当内核需要查找一个路径分量时，执行以下步骤：
- 计算哈希值：根据当前目录的dentry指针和分量名称，计算组合哈希值。
- 定位哈希桶：通过
dentry_hashtable[hash & mask]找到对应的哈希桶。 - 遍历链表：遍历桶内的dentry链表，比较
d_parent和d_name是否匹配。 - 返回结果：找到匹配的dentry则返回；否则返回NULL，触发底层文件系统的
lookup()。
nr_dentry的1/4左右，以平衡内存占用和查找效率。内核通过d_hash()和d_compare()函数支持文件系统自定义哈希和比较逻辑，适用于不区分大小写等特殊需求。
4.2.3 dcache哈希查找的SVG架构图
4.3 LRU回收机制
dcache虽然能显著加速路径解析，但dentry对象会占用大量内存。内核必须设计一套高效的回收机制，在内存压力增大时释放不再活跃的dentry。Linux内核采用LRU（Least Recently Used）链表来管理dcache的回收。
4.3.1 dentry的状态与LRU链表
每个dentry对象都有一个引用计数（d_count）和状态标志。根据引用计数和是否被文件系统使用，dentry分为以下状态：
| 状态 | 引用计数 | LRU链表位置 | 回收行为 |
|---|---|---|---|
| 使用中（in-use） | d_count > 0 | 不在LRU链表 | 不会被回收 |
| 未使用（unused） | d_count == 0 | 在LRU链表尾部 | LRU回收时优先淘汰 |
| 负缓存（negative） | d_count == 0 | 在LRU链表尾部 | 优先回收（文件已不存在） |
4.3.2 LRU回收的触发条件
dcache的LRU回收由内核的内存回收机制（kswapd）或直接回收（direct reclaim）触发。主要条件包括：
- 内存不足：系统可用内存低于阈值（
vm.min_free_kbytes）。 - dcache过大：dentry数量超过
dentry_max（由nr_dentry和dentry_ratio动态计算）。 - 手动触发：通过
/proc/sys/fs/drop_caches写入2或3。
4.3.3 LRU回收的执行流程
- 扫描LRU链表：从LRU链表头部（最久未使用）开始扫描，检查每个dentry的引用计数。
- 跳过使用中：若d_count > 0，跳过该dentry，将其移动到LRU链表尾部（保护活跃项）。
- 检查负缓存：若dentry是负缓存（无对应inode），直接释放。
- 尝试收缩：对于未使用的dentry，调用
d_prune_aliases()断开与inode的关联，然后释放dentry。 - 批量回收：一次回收操作通常释放
nr_to_scan个dentry（默认128个）。
4.3.4 LRU回收机制的SVG流程图
4.4 路径查找与dcache的协同优化
路径解析、dcache查找和LRU回收三者紧密协作，构成了VFS层路径查找的性能核心。以下表格总结了它们之间的协同关系：
| 组件 | 核心功能 | 性能瓶颈 | 优化方向 |
|---|---|---|---|
| path_walk | 逐分量解析路径字符串 | 路径深度、权限检查次数 | 减少路径深度、使用绝对路径 |
| dcache哈希 | 快速定位dentry | 哈希冲突、链表过长 | 增大哈希表、优化哈希函数 |
| LRU回收 | 管理dcache内存占用 | 回收过度导致命中率下降 | 动态调整回收阈值、保护工作集 |