iノードは何に適していますか？
ファイルに関する情報をディレクトリに直接保存するのではなく、 inodes に保存することは、追加のオーバーヘッドの価値があるのではないかと思います。オーバーヘッドを過大評価したり、重要なことを見落としたりしているのは良いことかもしれませんが、それが私が求めている理由です。
ハードリンクには「iノード」のようなものが必要だと思いますが、オーバーヘッドが私が思うほど大きい場合は、 理由のいずれか がそれを正当化するのではないかと思います。
- バックアップにハードリンクを使用することは賢明ですが、通常の操作の効率と比較した場合、バックアップの効率は十分に重要ではありません。
- この利点は、すべてのファイルへのアクセス中にハードリンクを使用するいくつかのファイルに対してのみ保持されるため、ハードリンクの速度もサイズのペナルティもありません。 オーバーヘッドに苦しむ
bunzip2やbcatのような同じ名前のバイナリのスペースを節約することはごくわずかです
Iノード/ハードリンクが悪いまたは役に立たないと言っているわけではありませんが、余分な間接参照のコストを正当化できますか（キャッシングは確かに大いに役立ちますが、特効薬ではありません）？
ハードリンクは重要ではありません。それらはiノードを持つ理由ではありません。それらは副産物です。基本的に、合理的なUNIXライクなファイルシステム設計（そしてNTFSでさえこの点で十分に近い）には無料のハードリンクがあります。
Iノードは、ファイルのすべてのメタデータ（変更時間、アクセス許可など）が格納される場所です。また、ディスク上のファイルデータの場所が保存される場所でもあります。このデータはどこかに保存する必要があります。
Iノードデータをディレクトリ内に保存すると、独自のオーバーヘッドが発生します。ディレクトリが大きくなるため、ディレクトリリストの取得に時間がかかります。ファイルアクセスごとにシークを保存しますが、各ディレクトリトラバーサル（ファイルにアクセスするにはいくつか必要であり、ファイルパス上のディレクトリごとに1つ）のコストは少し高くなります。最も重要なことは、ファイルをあるディレクトリから別のディレクトリに移動するのがはるかに難しくなることです。iノードへのポインタだけを移動するのではなく、すべてのメタデータを移動する必要があります。
Unixシステムでは、プロセスでファイルが開いている場合でも、ファイルの名前を変更したり、ファイルを削除したりできます。 （一部のUNIXバリアントでは、これをほぼ常に作成します。）これは実際には非常に重要なプロパティです。つまり、アプリケーションがファイルを「ハイジャック」できないことを意味します。ファイルの名前を変更したり削除したりしても、アプリケーションには影響しません。ファイルの読み取りと書き込みを続行できます。ファイルが削除された場合、プロセスがファイルを開かなくなるまで、データは残ります。これは、プロセスをiノードに関連付けることで容易になります。プロセスはファイル名に関連付けることができません。ファイル名はいつでも変更されたり、消えたりする可能性があるためです。
他のいくつかの要因を見逃している可能性があります。ディレクトリ内のファイル名からiノードを分離するとハードリンクが可能になりますが、ハードリンクがその分離の唯一の、または元の動機でさえあるとは思えません。
1978年7月から8月の「TheBellSystem Technical Journal」のコピーを持っています。これは彼らの特別号の1つで、タイトルは "Unix Time Sharing System" です。ここは、トンプソン、リッチー、および会社がバージョン6および7のUnixの説明を公開した場所であり、それを使用して何ができるかを示しています。
Iノードとファイルシステムの説明は表示されますが、設計の動機はありません。 RitchieとThompsonは、create（BSTJでのスペル）システムコールがiノードを作成して値を設定し、openシステムコールがiノードデータを保持できるOSテーブルに入力することに注意します。それ以降のファイルアクセスで。
重要な段落の1つは、i-listと呼ばれるiノードを保持するディスクのチャンクについて説明しています。
I-listの概念は、UNIXの珍しい機能です。実際には、ファイルシステムを編成するこの方法は、非常に信頼性が高く、扱いやすいことが証明されています。 ...また、ファイルシステムの整合性をチェックするための非常にシンプルで迅速なアルゴリズムを可能にします。..このアルゴリズムは、線形に編成されたiリストをスキャンするだけでよいため、ディレクトリ階層に依存しません。
— ソース
元の設計者は、iノードをデータから分離しておくと物事の信頼性が高まることを発見しました。
それを実現するための長年の経験を指摘できると思います。ディレクトリ階層がすべて割り当て（FAT）と混同されているMS-DOSやその他のファイルシステムは、かなり壊れやすいものです。 FATのセクターが悪化した場合、事態を回復することは非常に困難です。ただし、Unixディレクトリ内のセクターが故障した場合、ディスク上の別の場所にあるiノードはまだ存在しており、リンクカウントは、あるディレクトリに属していることを示しているため、回復できます。
ディレクトリでiノード番号を検索してからiノードでアクセス許可またはデータを検索するという明らかなオーバーヘッドは、OSによるファイルの処理を単純化するか、信頼性を高めることで補われるようです。
ハードリンクはファイルだけに使用されるのではありません。 .はファイルシステム内の実際のリンクであるため、すべてのディレクトリには少なくとも2つのファイルシステムリンクがあります---フルパス名と.リンク。 ..リンクを追加すると、ディレクトリに多くのハードリンクを含めることができます。
1つの実用的なiノードの例：
トリッキーな名前のファイル（例〜*）があり、それを削除する必要があります。
ls
~*
rm -rf ~*は$ HOMEに損害を与えるため、別の方法で削除する必要があります。
読む ここ iノードでファイルを削除する方法。
Iノードでファイルを削除します。
find . -type f -inum 1234 - exec rm -rf {} /;
わかりました。特殊文字をエスケープしてrmで削除するか、-トリックを使用できますが、それでもかまいません。