通常、iノードテーブルのサイズを変更できないのはなぜですか？

Unixファイルシステムには通常iノードテーブルがあり、このテーブルのエントリ数は通常、ファイルシステムの作成時に固定されています。これにより、十分なディスク容量を持つユーザーが空き容量がないという混乱したエラーメッセージを表示することがあり、問題を特定した後でも、それをどうするかについての簡単な解決策はありません。

しかし、（私には）ユーザーとシステム管理者に完全に透過的にiノードをオンデマンドで割り当てることにより、この混乱を回避することが非常に望ましいと思われます。あなたがかわいいハックに夢中なら、inodeテーブル自体をファイルにすることさえできます。したがって、ディスク上の空きスペースを見つける既存のコードを再利用できます。運がよければ、この結果を明示的に達成しようとせずに、ファイル自体の近くにiノードが存在することになるかもしれません。

しかし、誰も（私が知っている）実際にこれを行っていないので、おそらく私が見逃しているキャッチがあります。それが何であるか考えていますか？

iノードテーブルをファイルにしたとしましょう。次の質問は...そのファイルに関する情報をどこに保存しますか？したがって、MS-DOSパーティションテーブルのような「実際の」iノードと「拡張」iノードが必要になります。つまり、必要なのは1つだけです（または、おそらく数日です。たとえば、ジャーナルをファイルにすることもできます）。しかし、実際には、特別な場合、異なるコードがあります。そのファイルの破損も悲惨なものになります。また、ジャーナリングの前に、たとえば電源が切れたときなどに書き込まれているファイルが重度の損傷を受けたことがよくあったことを考慮してください。あなたのファイル操作はたくさんする必要があります、より堅牢な対の電源障害/クラッシュの/ etc。たとえば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も。