共 2 篇相关文章
这篇讲的是Linux文件系统中两个最核心的元数据结构——inode和dentry，以及它们如何协同工作来构建我们熟悉的文件目录。 作者从虚拟文件系统VFS的抽象层入手，解释了为什么需要这些结构来统一管理底层不同的实体文件系统（如ext4）。文章指出，inode是内核中文件对象的唯一标识，它存储了权限、属组、数据块位置等所有静态元数据，但刻意不包含文件名。而文件名与inode的映射关系，则由目录项dentry在内存中动态建立和维护。 通过阅读文件路径时内核的解析过程，文章清晰地展示了dentry如何通过内存中的树状结构，高效地缓存和还原出文件系统的目录层次。这种设计将稳定的磁盘结构与灵活的内存缓存分离，是Linux文件系统高性能的关键。 理解了inode和dentry，文章最后点明，文件链接的奥秘也迎刃而解：软链接拥有独立的inode和内容，而硬链接仅仅是为同一个inode在目录项中新增了一条名字映射，并通过引用计数管理生命周期。整篇文章从底层原理出发，把看似复杂的文件系统机制拆解得条理分明。
这篇讲的是一个生产环境中典型的“隐形地雷”：明明只是想更新一个动态库文件（.so），为什么用 cp 命令覆盖后，正在运行的程序就莫名崩溃了？作者从一次周会讨论的问题出发，抽丝剥茧地分析了这个现象的深层原因。 文章先厘清了 Linux 文件系统的两个关键概念：inode 存储文件元数据，dentry 建立文件名到 inode 的映射。核心分析由此展开：cp 和 mv 操作对正在被进程使用的文件影响截然不同。cp 命令本质是“打开目标文件并截断，然后写入新数据”，这个截断操作会通知内核释放该文件在内存中的所有页面映射。当程序再次执行到该库的代码时，会触发缺页中断，但因为原文件数据块已失效，内核无法正确填充内存，于是导致总线错误（bus error）或段错误（segment fault）。相比之下，mv 命令仅仅是重命名操作，只改变了目录项（dentry）的指向，并未影响文件本身（inode）及其内存映射，因此是安全的。 文章通过 strace 跟踪和进程内存映射的视角，清晰展示了故障现场。结论很明确：对于已被进程动态链接的库文件，在线更新的正确姿势是 mv（将新文件重命名为原名），而不是 cp。
