創建到另一個符號鏈接的符號鏈接是否有任何副作用？

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使用符號連接符號鏈接圖書館的處罰是長於路徑查找，也許甚至是跨越多個安裝點不太嚴重。

我還沒有看到關於這個問題的原始數據，但是從個人的經驗，我會說這是頂多一個小的性能損失，在大多數情況下並不明顯。性能命中與我聽說過的符號鏈接（沒有親眼見過）一起出現在（可能是不好的）實現中，其中系統分支用於查找某個符號鏈接的目標。

雖然我很喜歡看到關於符號鏈接和性能的「肉體」評論，因爲這是我在幾個月內第二次發現它，但沒有得出明確的結論。