创建指向另一个符号链接的符号链接是否有任何副作用？答案

【问题标题】：Does creating a symbolic link to another symbolic link have any side-effects?创建指向另一个符号链接的符号链接是否有任何副作用？
【发布时间】：2011-06-09 09:02:17
【问题描述】：

在 linux 机器上创建指向另一个符号链接的符号链接是否有任何副作用（特别是在性能方面）？

【问题讨论】：

标签： linux symlink

【解决方案1】：

一般来说，不会。从技术上讲，间接性会对性能产生非常轻微的影响，但您的应用程序不会注意到它。例如，大多数共享库都是符号链接的符号链接（例如 libQtCore.so -> libQtCore.so.4 -> libQtCore.so.4.7 -> libQtCore.so.4.7.1）。

【讨论】：

【解决方案2】：

这主要是对 Daniel Gallagher 论点的评论，但它不适合评论框，因此这将使其更具可读性。来自Wikipedia on symbolic links：

符号链接的早期实现将符号链接信息作为数据存储在常规文件中。该文件包含对链接目标的文本引用，以及将其表示为符号链接的指示符[需要澄清]。

这种方法速度慢，并且在小型系统上对磁盘空间的使用效率低下。一种称为快速符号链接的改进允许将目标路径存储在用于在磁盘（inode）上存储文件信息的数据结构中。该空间通常存储分配给文件的磁盘块地址列表。因此，可以快速访问具有短目标路径的符号链接。如果目标路径超过可用的 inode 空间，具有快速符号链接的系统通常会退回使用原始方法。原始样式被追溯称为慢符号链接。它还用于与其他或更旧版本的操作系统的磁盘兼容性。

虽然将链接值存储在 inode 内部保存了一个磁盘块和一次磁盘读取，但操作系统仍然需要解析链接中的路径名，这总是需要读取额外的 inode，并且通常需要读取其他的，可能还有很多，目录，处理文件列表和每个文件的 inode，直到找到与链接的路径组件匹配的内容。只有当链接指向同一目录中的文件时，“快速符号链接”才能提供比其他符号链接更好的性能。

因此，在 /usr/lib 中使用符号链接到库的符号链接的惩罚不如甚至可能跨越多个安装点的较长路径查找严重。

我还没有看到有关该主题的原始数据，但根据个人经验，我认为这至多是对性能的轻微影响，在大多数情况下并不明显。与我听说过的符号链接（没有亲眼看到）相结合的性能命中（可能很糟糕）在系统分叉用于查找某个符号链接的目标的实现中。

不过，我希望看到有关符号链接和性能的“肉体”cmets，因为这是几个月来我第二次研究它而没有得出明确的结论。

【讨论】：

【解决方案3】：

副作用

是的。在内核和/或应用程序拒绝遵循链之前，您只能将这么多的符号链接堆叠在一起。（因为循环检测在内存方面是昂贵的，尤其是在内核中，没有使用“seen”标志，而是限制了递归深度。）

【讨论】：

你有任何关于副作用信息的来源吗？
你应该引用你的参考资料。