もちろん、シンボリックリンクはスペースを占有しますが、名前とターゲット、その他のメタデータを格納するのに必要な数バイトしか必要ありません。
私の質問は、シンボリックリンクにかかるバイト数を決定できるかどうかということです。
$ 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
「数バイトの追加メタデータ」を含むシンボリックリンクの実際のサイズを印刷するコマンドはありますか？
ベストアンサー1
そのようなものですが、ファイルサイズは対応する精度レベルではうまく定義されていません。
シンボリックリンクは4つの部分で構成されています。
- エントリであるディレクトリに格納されているリンクの名前。
- 残りのメタデータを見つけるために使用される各ディレクトリエントリの追加のメタデータがあります。これは通常インデックスノードの位置です。また、各ディレクトリエントリには、ファイル名を埋め、バランスの取れたツリーやハッシュなどのデータ構造を保持するのに数バイトかかります。
- タイムスタンプなどのシンボリックリンク自体に関する追加のメタデータ。このメタデータは、空の一般ファイルなどの他のファイル形式にも存在します。
- リンクの宛先です。
ファイルシステムがシンボリックリンクに複数のハードリンクを持つことを許可する場合、最初の2つの部分はディレクトリエントリごとに表示され、最後の2つの部分はシンボリックリンクごとに1回だけ表示されます。
ext2/ext3/ext4から、シンボリックリンクのターゲット長が最大60バイトの場合、inodeに保存されます。質問してこれを確認できますdu。宛先が60バイト以下のシンボリックリンクの場合は0を報告し、より大きい宛先の場合は1ブロックを報告します。
通常のファイルと同様に、報告された番号にはduディレクトリエントリとinodeの保存は含まれません。シンボリックリンクが占めるスペースがどれだけあるかを正確に知りたい場合は、そのスペースも計算する必要があります。ほとんどの既存のファイルシステムはファイルシステムの作成時にinodeを割り当てるため、コストが分割されます。つまり、ディレクトリエントリのサイズはデータブロックの数に基づいて計算され、inodeはinodeプールのサイズに基づいて計算されます。
ディレクトリエントリ自体のサイズに関して、エントリが占める正確なバイト数は、ディレクトリ内の他のエントリによって異なります。ただし、ディレクトリは通常ブロック全体を占めるため、エントリをさらに作成すると、エントリが1つのブロックに収まらず、2番目のブロックが割り当てられるまで、ディレクトリサイズは変わりません。ディレクトリエントリがブロックにどのように格納されるかを正確に理解するには、ファイルシステムデバッガとファイルシステムフォーマットの基本的な理解が必要です。あるいは、ファイルシステム形式の良い理解と、ディレクトリに存在する他のエントリに関する知識が必要です。項目が生成される順序と、他の項目が削除される順序があります。
要約すると、「数バイトの追加メタデータ」は次のようになります。
- 可変サイズディレクトリエントリ。シンボリックリンクを作成しても効果がないか、ブロックが追加される可能性があります。
- インデックスノード。
それ以外の場合、ターゲットは0から1ブロックの間を占有する可能性があります。