別のシンボリックリンクへのシンボリックリンクを作成すると、副作用がありますか？
Linuxボックスで別のシンボリックリンクへのシンボリックリンクを作成すると、副作用（特にパフォーマンスの点）がありますか？
一般的には違います。技術的には、間接参照のveryわずかなパフォーマンスヒットが発生しますが、アプリケーションには気づかれません。例として、ほとんどの共有ライブラリはシンボリックリンクへのシンボリックリンクです（たとえば、libQtCore.so-> libQtCore.so.4-> libQtCore.so.4.7-> libQtCore.so.4.7.1）。
これは主にダニエルギャラガーの主張に対するコメントですが、コメントボックスに収まらないため、読みやすくなっています。 シンボリックリンクのウィキペディア から：
シンボリックリンクの初期の実装では、シンボリックリンク情報を通常のファイルのデータとして保存していました。ファイルには、リンクのターゲットへのテキストによる参照と、それをシンボリックリンクとして示すインジケーター（説明が必要）が含まれていました。
この方法は時間がかかり、小規模なシステムではディスク領域を効率的に使用できませんでした。高速シンボリックリンクと呼ばれる改善により、ディスク（inodes）にファイル情報を格納するために使用されるデータ構造内にターゲットパスを格納できるようになりました。このスペースは通常、ファイルに割り当てられたディスクブロックアドレスのリストを格納します。したがって、ターゲットパスが短いシンボリックリンクにはすばやくアクセスできます。高速シンボリックリンクを備えたシステムは、ターゲットパスが使用可能なiノードスペースを超えると、元の方法を使用するようにフォールバックすることがよくあります。元のスタイルは、遡って低速シンボリックリンクと呼ばれています。また、他のバージョンまたは古いバージョンのオペレーティングシステムとのディスク互換性のためにも使用されます。
リンク値をiノード内に保存すると、ディスクブロックとディスクの読み取りが節約されますが、オペレーティングシステムは、リンク内のパス名を解析する必要があります。リンクのパスコンポーネントとの一致が見つかるまで、ファイルのリストとそれぞれのiノードの両方。リンクが同じディレクトリ内のファイルを指している場合にのみ、「高速シンボリックリンク」は他のシンボリックリンクよりもはるかに優れたパフォーマンスを提供します。
したがって、/usr/libのライブラリのシンボリックリンクにシンボリックリンクを使用することのペナルティは、おそらく複数のマウントポイントにまたがる長いパスルックアップほど深刻ではありません。
私はこの件について生の数値を見たことがありませんが、個人的な経験から、それは多くの場合小さなパフォーマンスヒットであり、ほとんどの状況では目立たないと思います。私が聞いた（実際には見られない）シンボリックリンクと組み合わせたパフォーマンスヒットは、システムフォークを使用して特定のシンボリックリンクのターゲットを見つける（おそらく悪い）実装にあります。
シンボリックリンクとパフォーマンスに関する「より新鮮な」コメントを見たいと思います。これは、決定的な結論に達することなく調べたのは2、3か月で2回目だからです。
副作用
はい。カーネルやアプリケーションがチェーンの追跡を拒否する前に、多くのシンボリックリンクをスタックすることができます。 （特にカーネルでは、サイクルの検出はメモリの点でコストがかかるため、「seen」フラグは使用されず、代わりに再帰の深さが制限されます。）