ファイルに関する情報が保存されているかどうかを知りたいです。インデックスノードディレクトリに直接保存するよりも、追加のオーバーヘッドが価値があります。私がオーバーヘッドを過大評価しているか、重要なことを見落としているかもしれませんが、だからこそ見てください。
ハードリンクには「inode」のようなものが必要であることがわかりました。しかし、オーバーヘッドが実際に考えたのと同じ大きさであれば、何らかの理由正当化して下さい:
- バックアップにハードリンクを使用することは賢明ですが、バックアップの効率は通常の作業の効率に比べて十分に重要ではありません。
- ハードリンクの速度やサイズに不利益がないことは本当に重要です。なぜなら、この利点はただ存在するからです。複数のファイルについてアクセス時にハードリンクを使用するすべてのファイル間接費を負担する
- 同じ名前（たとえば、および
bunzip2）を持つ複数のバイナリの一部のスペースを節約するbcatことは無視できます。
inode /ハードリンクが悪いか役に立たないと言うわけではありませんが、これは追加の間接参照コストを正当化しますか？
ベストアンサー1
ハードリンクはポイントではありません。これはinodeを所有する理由ではありません。それらは副産物です。基本的に、合理的なUNIXに似たファイルシステム設計（この時点ではNTFSも十分に近い）には無料のハードリンクがあります。
inodeは、変更時間、権限など、ファイル内のすべてのメタデータが保存される場所です。また、ディスク上のファイルデータが保存される場所でもあります。このデータはどこかに保存する必要があります。
inodeデータをディレクトリに保存すると、わずかなオーバーヘッドが発生します。ディレクトリが大きくなるため、ディレクトリのリストが遅くなります。ファイルアクセスごとに1つのルックアップを保存できますが、ディレクトリ巡回（ファイルパスの各ディレクトリごとに1つずつ、ファイルにアクセスするために必要な複数の巡回）あたりのコストはわずかに高くなります。最も重要なことは、これがあるディレクトリから別のディレクトリにファイルを移動するのがより困難になることです。つまり、inodeへのポインタだけでなく、すべてのメタデータを移動する必要があります。
Unix システムでは、プロセスでファイルが開いていても、常にファイル名を変更したりファイルを削除したりできます。 （一部のUNIXバリアントではほとんど常に行われます。）これは実際には非常に重要な属性です。これは、アプリケーションがファイルを「ハイジャック」できないことを意味します。ファイル名を変更または削除してもアプリケーションには影響がなく、ファイルを読み書きすることができます。ファイルが削除されると、プロセスがファイルを再度開くまでデータは保持されます。これは、プロセスを inode と関連付けることによって促進されます。ファイル名はいつでも変更または消える可能性があるため、プロセスをファイル名に関連付けることはできません。
また、見ることができますスーパーブロック、アノード、ディレクトリエントリ、ファイルとは何ですか？