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