特別なデバイスファイルにiノードがあるのはなぜですか？

デバイスファイル自体はファイルではありません。これらは、Unixライクなオペレーティングシステムでデバイスを使用するためのI / Oインターフェイスです。これらはディスク上のスペースを使用しませんが、stat次のコマンドで報告されるようにiノードを使用します。

$ stat /dev/sda
      File: /dev/sda
      Size: 0               Blocks: 0          IO Block: 4096   block special file
Device: 6h/6d   Inode: 14628       Links: 1     Device type: 8,0

デバイスファイルはファイルシステムの物理的な iノードを使用しますか、なぜそれらを必要とするのですか？

簡単に言えば、物理的なファイルシステムのバッキングがある場合にのみ機能します/dev（そして、最新のLinuxディストリビューションを使用している場合は、おそらくそうではありません）。

長い答えは次のとおりです。

これはすべて、すべてがファイルであるという元のUNIX哲学に戻っています。この哲学は、UNIXを多用途にした理由の一部です。なぜなら、物理ハードウェアと直接やり取りするためにアプリケーションに特別なコードを持たなくても、ユーザー空間からデバイスと直接やり取りできるからです。

もともとは、/devデバイスファイルを置く有名な名前を持つ別のディレクトリでした。UNIXシステムの中にはまだこのアプローチを採用しているものがあり（OpenBSDはまだそうだと思います）、システムが実際に持っていないデバイス用のデバイスファイル（たとえば、すべてのファイル可能なすべてのディスク上の可能なパーティション）。これにより、メモリの容量と起動時の時間が節約されますが、ディスク容量が少し増えますが、初期のシステムは一般にメモリが非常に制約され、高速ではないため、トレードオフになります。これは一般に、「静的」と呼ばれます/dev。

最新のLinuxシステム（そしてFreeBSDとおそらく最新バージョンのSolarisも信じています）/devは、カーネル（またはSystemdを使用している場合はudev、カーネルがほとんど何もしないと信頼していないため）によって設定された一時的なインメモリファイルシステムです。 。これにより、メモリ（通常は数MB未満）と非常に小さい処理オーバーヘッドを犠牲にして、ディスク領域を節約できます。また、他にも多くの利点があり、最大の1つは、ホットプラグされたハードウェアを検出しやすいことです。これは一般に、ダイナミックと呼ばれ/devます。

ただし、どちらの場合でも、デバイスノードは通常のVFSレイヤーを介してアクセスされます。つまり、定義上、iノードが存在する必要があることを意味stat()します。これは/dev、iノードをメモリに格納するか、必要に応じて生成するため、動的を使用するシステムに/devは影響がありません。また、inodeはディスク上のほぼゼロのスペースを占め、ほとんどのファイルシステムには上限がないため、静的な場合はほぼゼロの影響です。それらまたは誰もが必要とする可能性が高いよりもはるかに多くの方法を提供します。

デバイスファイルにも権限があり、それらはiノードに保存されます。

ディレクトリは単にファイル名からiノードへのマッピングなので、名前が参照するもの（ファイル、シンボリックリンク、デバイス、FIFO、ソケット）に関するすべてがiノード内にある必要があり、他に置く場所はありません。

デバイスに関する情報はiノードに保存されます。メジャーデバイス番号とマイナーデバイス番号、アクセス許可、タイムスタンプなどがあります。通常のファイルではなくブロックまたはキャラクターデバイスであることを示すtypeフィールドがそこに格納されます。

デバイスのiノードは、ファイルのブロックマップを含むフィールドを使用しません。

iノードがないと、問題のデバイスに関するすべての情報を保持するためのファイル名しか取得できません。これは、「素敵な」デバイス名/dev/sdaは問題外であることを意味します/dev/ohci/sda。たとえば、のような特定のドライバに関連付けられる名前が必要です。

さらに重要なのinode（のように依存しているすべてのツールはstat、lsなど）の下に御馳走のパスに変更しなければならないであろう/dev特別な方法で。これは、現在の状況と比較して明らかな利点がない、非常に大量の作業になります。