古いスタイルの「遅い」シンボリックリンクの作成

「高速」シンボリックリンクを生成するのか、「遅い」シンボリックリンクを生成するのかを知る方法はなく、lnファイルシステムがシンボリックリンクを保存する方法を決定します。

光メディアのシンボリックリンク表現処理は、ソースファイルシステムではなく変換を処理するプログラムまたはメディアへのアクセスを提供するファイルシステムドライバに依存する。たとえば、mkisofsRock Ridge 拡張ま​​たはTRANS.TBLファイルを使用してシンボリックリンクを表すことができます。ハードリンクも処理できます。

「高速」シンボリックリンクと「遅い」シンボリックリンクが異なる動作をするという仮定は正しくありません。どちらもターゲットパスをテキストとして保存します。ここで最適化は、ディレクトリエントリのスペースを使用してそのテキストを保存することです（十分に短い場合）。パスが長すぎると、ファイルシステムはファイルの内容を保存するために別のブロックを使用するのと同じように、別のブロックを使用して透過的にパスを保存します。ディスクから2回読む必要があるため、遅くなりますが、実際には違いをほとんど感じません。これは、SSDまたはNVMeドライブがある場合に特に当てはまります。

代わりに、シンボリックリンクへの相対パスを使用できます。ファイルを別のディスクにコピーすると、ソースとターゲットが互いに同じ関係を持つ限り、シンボリックリンクは期待どおりに機能し続けます。ボーナスとして、相対パスは絶対パスより短い可能性が高いため、ディレクトリエントリに適している可能性が高くなります。

たぶん「ハード」リンクと「ソフト」リンクを意味するのでしょうか？ 「ソフト」リンクだけが象徴的です。ハードリンクは、「一般」ファイルと同様に、ディレクトリへのinode参照を機能します。

「ハード」リンクは理論的には高速ですが、「ソフト」リンクはファイルシステムを拡張できるという利点があります。

ハードリンクが必要な場合、フラグなしでコマンドlnが実行されてリンクを生成できないことがあります。-sこの-sフラグを使用すると、他のファイル（特殊形式）へのパスを含むソフトリンクまたはファイルが生成されます。このシンボリックリンクは少し遅いですが、オペレーティングシステムが新しいパスを読み取るためにファイルを開き、読み取りパスからファイルを再要求する必要があるため、少し遅くなります。ハードリンクを使用すると、ディレクトリエントリはファイルを直接指すため、上記のマルチステップ操作は発生せず、ファイルの最初のブロックに直接移動します。

「遅い」/「高速」シンボリックリンクは歴史です。ほとんどのファイルシステムには、ディレクトリ inode テーブルにスペースがあります。ファイルがinodeテーブル自体に入るほど小さい場合、ファイルは独自のブロック番号として生成されず、代わりにinodeテーブルにフラグが設定され、ファイルの内容がinodeエントリに直接保存されます。これは非常に小さなファイルでのみ機能し、シンボリックリンクはそのようなファイルの1つです。

このレベルのファイルシステムにデータを保存する方法をオペレーティングシステムに通知できないため、1つまたは別の保存方法を強制する方法は限られています。たとえば、非常に長いパスを使用してオーバーフロー inode エントリを保存することができます。同様に、通常のファイルシステムライブラリをバイパスしてディスクブロックを変更するプログラムを書くことができます（もちろん、ファイルシステムの更新はOSのタスクであるため、これらのタスクを拒否しようとするため、同じOS管理の問題も解決する必要があります）。責任）