シンボリックリンクのサイズ
もちろん、シンボリックリンクにはスペースが必要ですが、名前とターゲットに加えて、他のメタデータ用の数バイトを格納するために必要なスペースだけです
シンボリックリンクは実際にディスク使用量に違いを生じますか？
私の質問は、シンボリックリンクが使用しているバイト数を判断できるかどうかです。
$ touch alfa.txt
$ ln -s alfa.txt bravo.txt
Duとlsはどちらも「alfa.txt」である8を報告します。
$ du -b bravo.txt
8 bravo.txt
$ ls -l bravo.txt
lrwxrwxrwx 1 Steven None 8 Mar 8 18:17 bravo.txt -> alfa.txt
「他のメタデータの数バイト」が含まれたシンボリックリンクの実際のサイズを出力できるコマンドはありますか？
ある程度ですが、ファイルのサイズはその精度レベルでは明確に定義されていないことに注意してください。
シンボリックリンクには4つの部分があります。
- エントリのあるディレクトリに保存されているリンクの名前。
- 残りのメタデータを見つけるために、すべてのディレクトリエントリに存在する他のメタデータ。これは通常、iノードの場所です。さらに、各ディレクトリエントリには、たとえばファイル名を埋め込んだり、バランスの取れたツリーやハッシュなどのデータ構造を維持したりするために、さらに数バイトのコストがかかります。
- タイムスタンプなど、シンボリックリンク自体の他のメタデータ。このメタデータは、他のファイルタイプ（空の通常ファイルなど）にも存在します。
- リンクのターゲット。
ファイルシステムでシンボリックリンクに複数のハードリンクを設定できる場合、最初の2つの部分はディレクトリエントリごとにあり、最後の2つの部分はシンボリックリンクごとに1回だけ存在します。
ext2/ext3/ext4 では、シンボリックリンクのターゲットは、長さが最大で60バイトの場合、iノードに格納されます。 duに問い合わせることで確認できます。ターゲットが60バイト以下のシンボリックリンクの場合は0を報告し、大きなターゲットの場合は1ブロックを報告します。
通常のファイルと同様に、duによって報告される数値には、ディレクトリエントリとiノードのストレージが含まれていません。シンボリックリンクが占めるスペースを正確に知りたい場合は、それらも数える必要があります。ほとんどの古典的なファイルシステムは、ファイルシステムの作成時にiノードを割り当てるため、コストが分割されます。ディレクトリエントリのサイズはデータのブロック数に対してカウントされ、iノードはiノードプールサイズに対してカウントされます。
ディレクトリエントリ自体のサイズの場合、エントリが占める正確なバイト数は、ディレクトリに存在する他のエントリによって異なります。ただし、ディレクトリは通常、ブロックの整数を占めるため、エントリを作成する数が増えると、ディレクトリのサイズは、エントリが1つのブロックに収まらなくなり、2番目のブロックが割り当てられるまで、同じままになります。ディレクトリエントリがブロックにどのように格納されているかを正確に確認するには、ファイルシステムデバッガーとファイルシステムフォーマットについてのある程度の理解が必要です。ディレクトリ内、およびそれらが作成された順序と、他のエントリが削除された可能性があります。
要約すると、「他のメタデータの数バイト」は次のとおりです。
- 可変サイズのディレクトリエントリ。シンボリックリンクを作成しても、違いはないか、1つのブロックが追加されます。
- Iノード。
そして、ターゲットはそれに加えて0から1ブロックまでのどこかを占める可能性があります。
lsコマンドは、シンボリックリンクの実際のサイズを表示し、使用するiノードはカウントしません。 8が "alfa.txt"であると言うことで、あなたは完全に正しかった。これが、作成したシンボリックリンクの「実際のサイズ」です。繰り返しますが、他のすべてのファイルのサイズに含まれていないのと同じように、サイズには使用するiノードは含まれていません。長いパスへのシンボリックリンクを作成する場合、サイズはそのパスの長さを反映します。