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

Question

在Linux机器上创建符号链接到另一个符号链接是否有任何副作用(特别是在性能方面)？

Answer 1

一般来说,没有.从技术上讲,会有一个非常的间接轻微的性能损失,但它不会被察觉到你的应用程序.例如,大多数共享库是符号链接的符号链接(例如libQtCore.so - > libQtCore.so.4 - > libQtCore.so.4.7 - > libQtCore.so.4.7.1).

Answer 2

这主要是对Daniel Gallagher的论点的评论,但它不适合评论框,因此这将使其更具可读性.来自维基百科的符号链接:

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

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

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

因此,使用符号链接到库的符号链接的代价/usr/lib不如可能甚至跨越多个安装点的较长路径查找那么严重.

我没有看到关于这个主题的原始数字,但从个人经验来看,我认为它最多只是一个轻微的性能打击,在大多数情况下并不明显.结合我所听到的(未见过的)符号链接的性能命中一直在(可能是坏的)实现中,系统分叉用于查找某个符号链接的目标.

我很乐意看到关于符号链接和性能的"更有趣"的评论,因为这是几个月来第二次我对它进行了调查而没有得出明确的结论.

Answer 3

副作用

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