Unixファイルシステムには通常inodeテーブルがあり、このテーブルのエントリ数は通常ファイルシステムが作成されたときに固定されます。これにより、ディスク容量が多い人は空き容量がないという混乱を招くエラーメッセージが表示されます。
しかし、必要に応じてinodeを割り当てて、全体的な混乱を避け、ユーザーとシステム管理者に完全に透明にすることが（私にとっては）非常に望ましいようです。きちんとしたトリックが好きな場合は、inodeテーブル自体をファイルにして、すでに持っているコードを再利用してディスク上の空き容量を見つけることもできます。運が良ければ、この結果を明示的に取得しようとしなくても、ファイル自体の近くにインデックスノードが発生する可能性があります。
しかし、私が知っている限り、実際には誰もこれを実行しないので、問題が見つからない可能性があります。それは何か知っていますか？
答え1
inodeテーブルをファイルとして生成したと仮定すると、次の質問は...ファイルに関する情報をどこに保存しますか？したがって、「実際の」inodeやMS-DOSパーティションテーブルなどの「拡張」inodeが必要です。指定された場合は1つだけが必要です（またはいくつか - たとえば、日記帳もファイルとして保存）。しかし実際には特別な場合、他のコードがあるでしょう。このファイルが破損した場合、災害になる可能性があります。また、記録する前に、停電などにより記録中のファイルが重大に破損することが多いことを考慮してください。ファイル操作は次のようにする必要があります。たくさん停電・衝突などに比べてより頑丈です。たとえば、ext2よりもそうです。
既存のUnixファイルシステムは、よりシンプルでより強力なソリューションを見つけました。つまり、Xブロックごとに1つのinodeブロック（またはブロックグループ）を配置することです。その後、簡単な算術で見つけることができます。もちろん、（ファイルシステム全体を再構成せずに）さらに追加することは不可能です。停電中に作成中の inode ブロックが失われたり破損したりしても、いくつかの inode だけが失われます。これは、ファイルシステムの大部分を占めるよりもはるかに優れています。
より近代的なデザインは、次のようなものを使用します。Bツリー変形。 btrfs、XFS、ZFSなどの最新のファイルシステムには、inodeの制限はありません。
答え2
多くのファイルシステムには、動的に割り当て可能なinodeテーブル（またはそれに対応する倫理テーブル）があります（XFS、BTRFS、ZFS、VxFS ...）。
もともとUnix UFSにはファイルシステムの作成時に固定されたinodeがありましたが、ここから派生したファイルシステム（Linux EXT、Solaris UFS）は通常このスキームを続けます。強力で実装が簡単です。あまりにも多くのユースケースがあるので、1つの問題を避けるために新しいファイルシステムを設計することは正当化するのは簡単ではありません。
答え3
一部のファイルシステムはinodeを動的に割り当てることができます。私の考えでは、少なくともVeritas VxFS（= HP-UXのデフォルトファイルシステム、Solarisで利用可能なオプションの1つ）、およびXFS（RHEL 7の標準ファイルシステムタイプ）はそのように機能します。 。 BtrfsとIBMのJFSも同様です。