iノードテーブルが通常サイズ変更できないのはなぜですか？
Unixファイルシステムには通常iノードテーブルがあり、このテーブルのエントリ数は通常、ファイルシステムの作成時に固定されています。これにより、ディスクスペースが十分にあるユーザーに、空きスペースがないという混乱したエラーメッセージが表示されることがあり、問題が何であるかを理解した後でも、簡単な解決策はありません。
しかし（私には）必要に応じてユーザーとシステム管理者に完全に透過的にiノードを割り当てることにより、この混乱全体を回避することが非常に望ましいと思われます。かわいいハックに夢中になっている場合は、inodeテーブル自体をファイルにして、ディスク上の空き領域を見つけた既存のコードを再利用することもできます。運が良ければ、明示的にこの結果を達成しようとせずに、ファイル自体の近くのiノードで終わることさえあるかもしれません。
しかし、実際には誰も（私が知っている）これを行っていないため、おそらく私が見逃している問題点があります。それが何であるか考えていますか？
Iノードテーブルをファイルにしたとしましょう。次に、次の質問です...そのファイルに関する情報はどこに保存しますか？したがって、MS-DOSパーティションテーブルのように、「実際の」iノードと「拡張」iノードが必要になります。与えられた場合、あなたは1つだけ（またはおそらくいくつか-ジャーナルもファイルにするために）必要です。しかし、実際には特別なケースがあり、コードが異なります。そのファイルの破損も悲惨なものになります。また、ジャーナリングの前に、電源が非常に損傷した場合などに書き込まれていたファイルが一般的であったことを考慮してください。ファイル操作は、停電/クラッシュなどに対してlotより堅牢でなければなりません。たとえば、ext2などです。
従来のUnixファイルシステムでは、Xブロックごとにiノードブロック（またはブロックのグループ）を配置するという、よりシンプルな（そしてより堅牢な）ソリューションが見つかりました。次に、単純な計算によってそれらを見つけます。もちろん、それ以上追加することはできません（ファイルシステム全体を再構築しない限り）。また、電源が落ちたときに書き込んでいたiノードブロックを紛失/破損した場合でも、失われるのは数個のiノードだけであり、ファイルシステムの大部分よりもはるかに優れています。
より最近の設計では、 Bツリー バリアントなどを使用しています。 btrfs、XFS、ZFSなどの最新のファイルシステムは、iノードの制限の影響を受けません。
多くのファイルシステムには、動的に割り当て可能なiノードテーブル（またはそれに相当するもの）（XFS、BTRFS、ZFS、VxFS ...）があります。
元のUnix UFSにはファイルシステムの作成時に修正されたiノードがあり、それから派生したファイルシステム（Linux EXT、Solaris UFS）はしばしばこのスキームを継続しました。堅牢で実装が簡単です。非常に多くのユースケースが適しています。1つの問題を回避するためだけに新しいファイルシステムを設計することは、正当化するのが容易ではありません。
動的にiノードを割り当てるファイルシステムがあります。頭上から、少なくともVeritas VxFS（= HP-UXのデフォルトファイルシステム、およびSolarisで利用可能な選択肢の1つ）とXFS（RHEL 7の標準ファイルシステムタイプ）が機能します。そのように。 BtrfsとIBMのJFSも。