Unix文件系统通常有一个inode表，并且该表中的条目数通常在文件系统创建时是固定的。这有时会导致拥有大量磁盘空间的人收到关于没有可用空间的令人困惑的错误消息，即使他们弄清楚问题所在，也没有简单的解决方案来解决这个问题。
但（对我来说）似乎非常希望通过按需分配 inode 来避免整个混乱，并且对用户和系统管理员完全透明。如果您喜欢巧妙的技巧，您甚至可以将 inode 表本身设置为一个文件，从而重用您已有的代码来查找磁盘上的可用空间。如果幸运的话，您甚至可能最终得到文件本身附近的索引节点，而无需明确尝试实现此结果。
但据我所知，没有人真正这样做，所以我可能遗漏了一个问题。知道它可能是什么吗？
答案1
假设您确实将索引节点表创建为文件；那么下一个问题是...您在哪里存储有关该文件的信息？因此，您需要“真实”inode 和“扩展”inode，例如 MS-DOS 分区表。鉴于，您只需要一个（或者可能几个 - 例如，将您的日记也作为一个文件）。但实际上你会有特殊情况，不同的代码。该文件的任何损坏也将是灾难性的。并考虑到，在记录日志之前，正在写入的文件很常见，例如在断电时严重损坏。您的文件操作必须是很多与电源故障/崩溃/等相比更稳健。比它们在例如 ext2 上的情况要多。
传统的 Unix 文件系统找到了一个更简单（也更健壮）的解决方案：每 X 个块放置一个 inode 块（或块组）。然后你可以通过简单的算术找到它们。当然，那么不可能添加更多（不重组整个文件系统）。即使您在断电时丢失/损坏了正在写入的索引节点块，也只是丢失了一些索引节点，这比文件系统的很大一部分要好得多。
更现代的设计使用诸如B树变体。 btrfs、XFS 和 ZFS 等现代文件系统不受 inode 限制。
答案2
许多文件系统确实有一个动态可分配的 inode 表（或其道德上的等价物）（XFS、BTRFS、ZFS、VxFS...）
最初的 Unix UFS 虽然具有在文件系统创建时固定的 inode，但从它派生的文件系统（Linux EXT、Solaris UFS）通常延续该方案。它功能强大且易于实施。如此多的用例都很适合，因此设计一个新的文件系统只是为了避免一个问题并不容易证明是合理的。
答案3
有些文件系统可以动态分配 inode：在我看来，至少 Veritas VxFS（= HP-UX 的默认文件系统，Solaris 上可用的选择之一）和 XFS（RHEL 7 上的标准文件系统类型）可以工作那样。 Btrfs 和 IBM 的 JFS 也是如此。