Linux 创建到另一个符号链接的符号链接有任何副作用吗？
声明：本页面是StackOverFlow热门问题的中英对照翻译，遵循CC BY-SA 4.0协议，如果您需要使用它，必须同样遵循CC BY-SA许可，注明原文地址和作者信息，同时你必须将它归于原作者（不是我）：StackOverFlow
原文地址: http://stackoverflow.com/questions/4695241/
Warning: these are provided under cc-by-sa 4.0 license. You are free to use/share it, But you must attribute it to the original authors (not me):
StackOverFlow
Does creating a symbolic link to another symbolic link have any side-effects?
提问by 5gfbtest
Does creating a symlink to another symlink on a linux box have any side effects (specifically in terms of performance)?
在 linux 机器上创建指向另一个符号链接的符号链接是否有任何副作用（特别是在性能方面）？
回答by Daniel Gallagher
In general, no. Technically, there will be a veryslight performance hit for the indirection, but it won't be noticeable to your application. As an example, most shared libraries are symlinks to symlinks (e.g. libQtCore.so -> libQtCore.so.4 -> libQtCore.so.4.7 -> libQtCore.so.4.7.1).
一般来说，没有。从技术上讲，间接访问的性能会受到非常轻微的影响，但您的应用程序不会注意到它。例如，大多数共享库都是符号链接的符号链接（例如 libQtCore.so -> libQtCore.so.4 -> libQtCore.so.4.7 -> libQtCore.so.4.7.1）。
回答by user562374
side effects
副作用
Yes. You can only stack so much symbolic links together before the kernel and/or application refuse to follow the chain. (Because cycle detection is costly memory-wise, especially so in the kernel, no "seen" flags are used, and instead the recursion depth is capped.)
是的。在内核和/或应用程序拒绝跟随链之前，您只能将这么多符号链接堆叠在一起。（因为循环检测在内存方面是昂贵的，尤其是在内核中，没有使用“seen”标志，而是递归深度被限制。）
回答by Daniel Andersson
This is mostly a comment to Daniel Gallagher's argument, but it doesn't fit in the comment box, so this will make it more readable. From Wikipedia on symbolic links:
这主要是对 Daniel Gallagher 论点的评论，但它不适合评论框，因此这将使其更具可读性。从维基百科上的符号链接：
Early implementations of symbolic links stored the symbolic link information as data in regular files. The file contained the textual reference to the link's target, and an indicator[clarification needed] denoting it as a symbolic link.
This method was slow and an inefficient use of disk-space on small systems. An improvement, called fast symlinks, allowed storage of the target path within the data structures used for storing file information on disk (inodes). This space normally stores a list of disk block addresses allocated to a file. Thus, symlinks with short target paths are accessed quickly. Systems with fast symlinks often fall back to using the original method if the target path exceeds the available inode space. The original style is retroactively termed a slow symlink. It is also used for disk compatibility with other or older versions of operating systems.
Although storing the link value inside the inode saves a disk block and a disk read, the operating system still needs to parse the path name in the link, which always requires reading additional inodes and generally requires reading other, and potentially many, directories, processing both the list of files and the inodes of each of them until it finds a match with the link's path components. Only when a link points to a file in the same directory do "fast symlinks" provide significantly better performance than other symlinks.
符号链接的早期实现将符号链接信息作为数据存储在常规文件中。该文件包含对链接目标的文本引用，以及将其表示为符号链接的指示符[需要澄清]。
这种方法很慢，而且在小型系统上对磁盘空间的使用效率很低。一项称为快速符号链接的改进允许在用于在磁盘（inode）上存储文件信息的数据结构中存储目标路径。该空间通常存储分配给文件的磁盘块地址列表。因此，可以快速访问具有短目标路径的符号链接。如果目标路径超过可用的 inode 空间，具有快速符号链接的系统通常会回退到使用原始方法。原始样式追溯称为慢速符号链接。它还用于与其他或旧版本操作系统的磁盘兼容性。
虽然将链接值存储在 inode 中节省了一个磁盘块和一个磁盘读取，但操作系统仍然需要解析链接中的路径名，这总是需要读取额外的 inode 并且通常需要读取其他的，可能很多，目录，处理文件列表和每个文件的 inode，直到找到与链接的路径组件匹配。只有当链接指向同一目录中的文件时，“快速符号链接”才能提供比其他符号链接更好的性能。
Thus the penalty of using symlinks to symlinks for libraries in /usr/libis less severe than longer path lookups that perhaps even span several mount points.
因此，在库中使用符号链接到符号链接的惩罚/usr/lib不如更长的路径查找严重，甚至可能跨越多个挂载点。
I haven't seen raw numbers on the subject, but from personal experience I'd say it's at most a minor performance hit, not noticeable in most circumstances. The performance hits in combination with symlinks I've heard about (not seen in person) has been in (probably bad) implementations where system forks are used to find the target of a certain symlink.
我还没有看到有关该主题的原始数据，但根据个人经验，我认为这最多只是对性能造成轻微影响，在大多数情况下并不明显。结合我听说过的符号链接（没有亲眼见过）的性能命中已经出现在（可能是糟糕的）实现中，其中系统分支用于查找某个符号链接的目标。
I'd love to see "fleshier" comments concerning symlinks and performance though, since this is the second time in a couple of months that I've looked into it without coming to a definitive conclusion.
不过，我很想看到关于符号链接和性能的“更丰富”的评论，因为这是几个月来我第二次在没有得出明确结论的情况下对其进行研究。
