ハードリンク
ファイルoriginal.txt
が与えられると、ハードリンクhardlink.txt
は同じiノードを指し、original.txt
が削除されても存在し続けます。
シンボリックリンク
ファイルoriginal.txt
が与えられると、シンボリックリンクsymlink.txt
はファイル名を指します。
質問:どちらが速いか、どちらが小さいか?
私の直感によると、ハードリンクは元のファイルと見分けがつかないため、高速になります。ただし、すべてはシンボリックリンクの速度に依存します。
また、どちらがハードディスクの空き容量を減らしますか?
this one のような質問のように、測定に基づいた回答を見たいのですが、サイズと速度について簡単に触れていますが、詳細は説明していません。
シンボリックリンクは、リンクされたファイルへのパスを含む新しいファイルを作成します。したがって、実際の新しいファイルを作成します。これは、宛先ファイル(リンクが指すファイル)へのパス(相対または絶対)のサイズとほぼ同じです。
ハードリンクは、ディレクトリ(つまり、ディレクトリのinode/names-pairsを実際に含む特別なファイル)に新しいエントリを作成するだけなので、新しいものは作成されません-特定のディレクトリがすでに「いっぱい」でない限り、inode/name -ペアテーブルは、リンクのエントリ用のスペースを確保するために増やす必要があります(たとえば、1024から2048(kバイト))。
システムはリンクと実際のファイルの両方の2つのファイルを読み取る必要があるため、シンボリックリンクには時間がかかると思います。さらに、おそらくリンクファイルの処理(パスの解析)と、場合によっては別のパーティションまたは物理ディスクを使用する必要があります。ハードリンクは、実際のファイルを読み取る必要があります。すべてのハードリンクは「同等に作成」されていることを忘れないでください。作成された後、どのリンクが最初であったか(「ソース」であり、「宛先」であった)はマットではありません。
シンボリックリンクは間接的なレベルを追加するため、ハードリンクよりも開くのに時間がかかりますが、一般的なユースケースで顕著な違いを生むにはおそらく十分ではありません。
シンボリックリンクのディスク上のサイズは、ファイルシステムの実装によって異なります。特にリンクされたパス名が長すぎてファイルデータ構造に収まらない場合は、「高速シンボリックリンク」を使用して名前ストレージを最適化する最新のファイルシステムと同じサイズか、それ以外の場合は少し大きいと思います。
一度開いたら、シンボリックリンクとハードリンクのどちらを使用しても、読み取り/書き込み操作に関する限り、違いはありません。
編集:シンボリックリンクは、リンクされたファイルへのパスをどこかに保存する必要があります。元々、これはデータブロックで行われました。その後、ほとんどのファイルシステムは、このパスがファイルデータ構造自体に格納される高速シンボリックリンクを実装し、読み取りスペースとディスクスペースの両方を節約しました。