页缓存按需加载：read()时检查偏移量是否命中，未命中则page-in；dentry和inode缓存加速路径解析与元数据访问；脏页策略平衡性能与安全；drop_caches仅限调试，非优化手段。
页缓存怎么决定要不要从磁盘读数据？
页缓存不是“预加载所有文件”，而是按需响应：每次 read() 系统调用进来，内核先查对应文件偏移量是否已在内存页中。命中就直接拷贝；未命中则触发一次同步或异步的磁盘读取（page-in），再把数据塞进页缓存并返回——整个过程对应用透明。
关键点在于：它只缓存你真正访问过的那部分，不是整个文件。比如用 head -n 100 big.log，通常只加载前几页（约 4–8KB），不会把几百 MB 的日志全拉进内存。
- 频繁随机读小文件（如 Web 静态资源）→ 页缓存命中率高，I/O 大幅下降
- 顺序写大文件（如数据库 WAL）→ 数据先落页缓存标记为脏页，后台线程异步刷盘
- 用
mmap()映射文件 → 也走同一套页缓存，但缺页异常（page fault）触发加载
inode 和 dentry 缓存为什么不能被忽略？
打开一个文件不只是读内容，还得先找到它：open("/var/log/nginx/access.log") 要逐级解析 / → var → log → nginx → access.log。每一步都依赖 dentry（路径名到 inode 的映射）和 inode（元数据：大小、权限、mtime 等）。这些不缓存，ls、find、甚至每次 open() 都得反复读磁盘目录块。
-
dentry缓存失效快（比如其他进程重命名了同级文件），但命中时几乎零开销 -
inode缓存更稳定，尤其对只读文件；改权限或时间戳会触发更新 - 参数
vm.vfs_cache_pressure=50可降低内核回收它们的倾向，避免小文件密集场景下反复重建
脏页刷写策略怎么影响写入性能和数据安全？
写操作默认走“延迟刷盘”：应用调用 write() 后，数据进页缓存、标为脏页，立刻返回成功——这极大提升吞吐，但也带来风险：断电即丢。
控制开关在两个内核参数：vm.dirty_background_ratio（后台线程开始刷的阈值）和 vm.dirty_ratio（应用阻塞等待刷盘的硬上限）。默认分别是 10% 和 20%，对 SSD + 高并发写服务往往太宽松。
- 写负载重（如日志聚合、消息队列落盘）→ 建议调低：如
dirty_background_ratio=5、dirty_ratio=10 - 强调数据安全（如金融交易中间件）→ 可配合
fsync()或挂载选项data=ordered，但别盲目设vm.dirty_ratio=0（会强制同步，卡死写入） - 注意：这些是百分比，基准是“可用内存 + 页缓存总量”，不是总物理内存
什么时候该清缓存？又为什么大多数时候不该碰？
echo 3 > /proc/sys/vm/drop_caches 确实能立刻释放 pagecache/dentry/inode，但它不是“优化”，而是“急救”：仅适用于调试、压测前后隔离干扰，或极少数因缓存长期驻留导致 OOM 的边缘情况。
Linux 的缓存设计哲学是 “有空闲就用，有需要就让”——当应用申请内存时，内核自动回收冷缓存页（LRU），根本不需要手动干预。强行清空反而造成后续请求全部 miss，引发一波磁盘风暴。
- 真正该看的是
free -h输出里的available列，不是free或cached - 如果
available持续接近 0 且 swap 在用 → 问题不在缓存，而在内存泄漏或配置过载 -
drop_caches必须配sync前置执行，否则可能丢掉未刷脏页
