私は現在、W. Richard Stevens 著の Advance UNIX Programming という本を読んでいますが、UNIX 上のすべてのファイルには番号が付けられており、ファイル名はユーザーの利便性のために付けられているだけであると書かれています。ディレクトリに入ると、システムは入力された名前の番号を検索します。
どうやって番号を検索するのだろう？ ファイルはバイナリ検索で見つけられるように名前順に保存されているのだろうか？ それとも、リストの最後に新しいファイルを追加するだけなのだろうか？
答え1
さまざまなファイルシステム形式があり、さまざまなシナリオでのパフォーマンス (大きなディレクトリと小さなディレクトリ、読み取りと書き込み、同時アクセスなど)、設計のシンプルさ (バグの可能性、開発の労力など)、ディスクのオーバーヘッド (ファイル コンテンツ以外の目的で使用されるスペース) などに応じて妥協点が異なります。
古いファイルシステム（例：UFS、FFS、拡張子2、 オリジナル拡張子3、…）は、ディレクトリをエントリの配列（各エントリにはファイル名、inode 番号、場合によっては追加のメタデータが含まれます）として保存し、線形検索を行う傾向があります。新しいファイルは、配列の最初の空きエントリに追加されます。空きエントリがない場合は、まず配列が拡張されます。このため、ディレクトリが大きいとパフォーマンスが低下します。
新しいファイルシステム（例：拡張子3オプションでdir_index、拡張子4、ゼフス、btrfs、ライザーフ、HFS、HFS+、…）は、ディレクトリを対数時間の検索、ある種のバランス検索ツリー、ハッシュテーブル、またはこれら2つの組み合わせ（ハッシュのバランス検索ツリー）のデータ構造として保存する傾向があります。Bツリーこれにより、ファイルシステムのコードはより複雑になりますが、大きなディレクトリでもパフォーマンスは良好に保たれます。
答え2
この数字はiノード. Linuxファイルシステムの中で最も人気のあるものの1つであるExt4はハッシュツリーを利用しています。kernel.org - Ext4 ディスクレイアウト。
ハッシュツリーの詳細については、ウィキペディア。
答え3
これはファイル システムに依存します。昔、Unix ディレクトリは本質的に 16 バイトのレコード (内部番号に 2 バイト、ファイル名に 14 バイト) で構成されるファイルでした。これが、昔からファイル名に 14 文字の制限があった理由です。レコードはソートされていなかったため、ファイル全体の線形検索が必要でした。
Linux の Ext4 などの最新のファイル システムには、検索を高速化するためのハッシュ テーブルがあります。
答え4
ペダント注意：説明が完全ではありません。ファイル名は、ユーザーの利便性のためだけのものではありません。ファイル名は、非常にUnix ベースのシステムでは重要です。
inode 番号はファイルシステム モジュールによって選択されるため、意味を持ちません。元々、inode 番号はディスク上に保存されている inode テーブル内のスロットを識別していました。システムの他の部分は、 や など、特定の意味を持つファイルにアクセスする必要があり/dev/tty1ます/etc/passwd。
cat特定の言葉に縛られることなく、「便利さ」は、やなどのコマンドをed名前で選択するためのユーザー インターフェイスを提供するために使用されるメカニズムを説明するにはあまりにも些細なことです。
ファイル名のディレクトリがなかったら、これらの用途をサポートするために、すぐに inode 番号の名前の非常によく似たレジストリを発明しなければならなくなるでしょう。
ディレクトリ エントリ.とに..も特別な意味があります。仮想ファイル システムは、procファイル名を使用して独自の意味を提供します。たとえば、/proc/1/commプロセス 1 に関する情報を提供するために使用できます。VFS では、異なるファイル システムも使用できます。これらのファイル システムは、UNIX に基づいている必要はなく、inode 番号のまったく同じ概念で動作しない可能性があります。
ZFS は、ファイル名と、権限のような inode メタデータの両方が別のレイヤーに属すると考えているようです。これがどのような利点をもたらすのかはまだわかりません。ネストされたファイルシステムを保存するために使用される場合、ファイルと同等のオブジェクトにさまざまなパフォーマンス ノブを提供する方法であるように思われます。
また、ユーザーは通常、inode 番号でファイルを開くことはできません。もし可能であれば、ファイルを含むディレクトリの権限を通じてファイルへのアクセスを制御することはできません...
最後の点を別の視点から見ると、それはディレクトリの機能であると言えます。ディレクトリの原則はファイル名をマップすることなので、それがなければ実際には何の効果もありません。
待ってください、ファイルへの参照のコンテナ、つまり「ハードリンク」としての効果は依然としてある、と言うかもしれません。複数のディレクトリにファイルをリストすることができます。あるディレクトリ ( unlink) からファイルを削除しても、別のディレクトリに残っている場合は、実際には削除されません。ハードリンクは UNIX 実装の興味深い部分ですが、私の知る限り、実際には何の役にも立ちませんでした。一般的には、混乱を招く機会としか見なされていません。機能が必要かどうかを実際に考慮することなく、興味深い機能を簡単に提供できるため、実装の詳細を公開した例です。「10 億ドルのミス」に似ていますが、この特定の設計上の欠陥はそれほど危険ではありませんでした。
そうは言っても、ディレクトリがその中に含まれるファイルの存在を保証する方法には注目する価値があります。ファイルを識別する別のシステムを実装したい場合は、ファイルを削除すると、存在しないファイルを参照するエントリが残る可能性、または後で同じ inode 番号が割り当てられた新しい無関係なファイルが残る可能性を考慮する必要があります。