我们仍然通过举例来说明。如上图所示，我们要在目录 a 下创建一个链接文件 b，并将 b 链接到到 c 目录下的文件 d。那么 link 操作会先对目录 a 进行加锁，然后对文件 d 进行加锁。由于 link 的对象不能是目录，因此加锁的顺序一定是先对目录加锁，再对文件加锁。由此 link 操作有很确定的加锁顺序，所以一个 link 操作不会与另一个 link 操作产生死锁。同时，由于 rename 操作会先对两个目录进行加锁，所以也不可能与 link 操作产生死锁。最后，当目录 a 和文件 d 在名字空间树状结构的同一分支上时，a 不会是 d 的子孙（否则 d 就不会是一个文件，而是一个目录）。因此当目录 a 和文件 d 在名字空间树状结构的同一分支上时，先对 a 加锁再对 d 加锁，也一定满足“从上到下”的加锁顺序。由此 link 操作不会与其他元数据操作产生死锁。

“link 操作的对象不能是目录”这个规定的初衷似乎是为了防止出现目录的无穷嵌套，却同时也简化了 link 操作的死锁问题。可以看出，这种非常规的元数据操作确实比较麻烦，需要考虑很多情况及其与其他元数据操作的关系。

6. 元数据组织方式对元数据加锁机制的影响

通过上面的介绍我们可以发现一个问题，为什么一般的元数据操作可以通过一个“从上到下”的加锁顺序就成功地避免了死锁隐患，而 rename 操作与 link 操作却需要很多特殊的处理？实际上这与 Linux 文件系统中元数据的组织方式有关。在 Linux 的 VFS 中，元数据的组织方式是基于父子关系的树状结构来构建的，比如每个 dentry 结构里都有 d_parent 域指向其父目录的 dentry 结构。因此，VFS 知道所有关于父子关系的信息。对于那些加锁对象的关系属于父子关系范畴的元数据操作，VFS 可以很轻松地指定这些操作对象的加锁顺序，从而避免死锁。而对于 rename 操作与 link 操作，它们的加锁对象的关系有可能不在父子关系的范畴内，于是 VFS 就无法明确这些操作对象之间的关系，也就很难相应地制定加锁顺序，从而也就出现了上面所介绍的那些特殊处理。也就是说，当文件系统要对元数据进行加锁时，它只能根据自己所能看到的元数据组织视图来指定加锁顺序。Linux 文件系统无法对所有元数据操作进行一致的加锁机制，本质上是由于其元数据的组织方式与加锁机制所需要的视图不一致所导致的。

作为最广泛采用的开源操作系统，Linux 的设计和机制都是很多人学习和研究的参照和样板，其实我们可以将眼光扩展开来，对其中的一些设计思路进行改变甚至颠覆，这在分布式文件系统领域更加普遍。比如 Google 文件系统所提出的全内存元数据的组织设计，由此带来了文件系统设计方面的许多新优势和新问题。当 Google 将其文件系统的设计以论文的形式发表后，就得到了大家广泛的关注，互联网海量存储及云计算所所提出的新挑战也促使大家探索存储方面的新突破。Yahoo! 模仿 Google 的文件系统及其他相关技术推出了自己的开源项目 Hadoop，其中 HDFS 更是想复制 Google 文件系统的成功，却无奈最终效果无法企及。从 HDFS 的源码中可以看出，它对 Google 文件系统的模仿其实比较表面，特别是元数据服务器，并没有看透 Google 文件系统的精髓所在，这也许也是其目前性能瓶颈的关键原因之一。DCFS3（Dawning Cluster File System v3）是中国科学院计算技术研究所研发的机群文件系统，旨在探索高性能低成本的并行 I/O 系统的新思想和新技术。DCFS3 也实现了全内存元数据的组织方式，其内存元数据的写回方式与 HDFS 相比，有很大的灵活性。从学术的角度来看，Google 文件系统也有其不足，它不支持标准的 VFS 架构，因此无法轻易地为通用文件系统所参考。无论如何，Google 文件系统是一个成功的架构，它支撑了 Google 众多产品及服务的正常运转。了解 Google 文件系统是一个很有意思的过程，大家依然按照本文的思路，从元数据加锁机制的角度去了解 Google 文件系统元数据的设计，可以探寻其全内存元数据给元数据组织方式带来的变化和对元数据加锁机制的影响。这部分内容已经超出了本文的讨论范围，感兴趣的读者可以根据后面的“参考资源”所列出的文献去阅读相关的论文。

文件系统与存储系统的设计本身就是一个很灵活、有很大发挥余地的领域；当然，同时也是一项非常具有挑战性的工作，需要扎实的基础知识和开阔的设计灵感。这也许就是系统设计的魅力所在。（责任编辑：A6）