创建到另一个符号链接的符号链接是否有任何副作用？

Question

创建一个符号链接到另一个符号链接在Linux上有任何副作用（特别是在性能方面）？

Answer 1

在一般情况下，没有。从技术上讲，间接性会有一个很小的性能影响，但它对于你的应用程序来说并不明显。例如，大多数共享库都是符号链接符号链接（例如libQtCore.so - > libQtCore.so.4 - > libQtCore.so.4.7 - > libQtCore.so.4.7.1）。

Answer 2

副作用

是。在内核和/或应用程序拒绝遵循链条之前，您只能将很多符号链接堆叠在一起。 （因为循环检测代价昂贵，特别是在内核中，所以没有使用“看到”标志，而是递归深度被限制。）

Answer 3

这主要是对Daniel Gallagher的论点的评论，但它并没有不适合评论框，所以这会使其更具可读性。从Wikipedia on symbolic links：

符号链接的早期实现将符号链接信息存储为常规文件中的数据。该文件包含链接目标的文本参考，以及一个指示[需要说明]，将其表示为符号链接。

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

尽管在inode中存储链接值可节省磁盘块和磁盘读取，但操作系统仍然需要解析链接中的路径名，这通常需要读取其他inode，并且通常需要读取其他节点，目录，处理文件列表和每个文件的inode，直到找到与链接的路径组件相匹配的文件。只有链接指向同一目录中的文件时，“快速符号链接”才能提供比其他符号链接显着更好的性能。

因此，在/usr/lib使用符号连接符号链接图书馆的处罚是长于路径查找，也许甚至是跨越多个安装点不太严重。

我还没有看到关于这个问题的原始数据，但是从个人的经验，我会说这是顶多一个小的性能损失，在大多数情况下并不明显。性能命中与我听说过的符号链接（没有亲眼见过）一起出现在（可能是不好的）实现中，其中系统分支用于查找某个符号链接的目标。

虽然我很喜欢看到关于符号链接和性能的“肉体”评论，因为这是我在几个月内第二次发现它，但没有得出明确的结论。