为什么通常无法调整索引节点表的大小？

Unix文件系统通常具有一个inode表，并且在创建文件系统时该表中的条目数通常是固定的。有时这会导致拥有大量磁盘空间的人收到关于没有可用空间的错误消息，甚至在他们弄清楚问题出在哪里之后，也没有解决该问题的简便方法。

但是（对我而言）似乎非常需要通过对用户和系统管理员完全透明地按需分配索引节点来避免整个混乱。如果您喜欢可爱的技巧，甚至可以使inode表本身成为一个文件，然后重用已经拥有的代码来在磁盘上找到可用空间。如果幸运的话，您甚至可能最终在文件本身附近放置索引节点，而没有明确尝试实现此结果。

但是实际上没有人（我知道）这样做，所以可能我缺少一个陷阱。知道会是什么吗？

假设您确实使inode表成为文件；那么下一个问题是...您在哪里存储有关该文件的信息？因此，您将需要像MS-DOS分区表一样的“实际” inode和“扩展” inode。假设您只需要一个（或可能只有几个，例如，也可以将日记记为文件）。但是实际上您会遇到特殊情况，不同的代码。该文件的任何损坏也将是灾难性的。并且请考虑一下，在记录日志之前，对于正在写入的文件（例如，断电严重损坏），这很常见。你的文件操作必须是一个很多更强大的对电源故障/崩溃/等。比他们以前的版本，例如ext2。

传统的Unix文件系统找到了一个更简单（更健壮）的解决方案：每X个块放入一个inode块（或一组块）。然后，您可以通过简单的算术找到它们。当然，那么就不可能添加更多（不对整个文件系统进行重组）。即使电源中断时您正在写入的inode块丢失/损坏，也只会丢失几个inode，远胜于文件系统的大部分。

更现代的设计使用B树变体之类的东西。诸如btrfs，XFS和ZFS之类的现代文件系统不受inode限制的困扰。

许多文件系统的确有一个可动态分配的索引节点表（或它的等同概念）（XFS，BTRFS，ZFS，VxFS ...）

尽管原始的Unix UFS具有在文件系统创建时固定的inode，并且从它衍生的文件系统（Linux EXT，Solaris UFS）通常会继续使用该方案。它功能强大且易于实现。如此多的用例是一个很好的选择，因此设计新的文件系统只是为了避免出现一个问题并不容易。

有一些文件系统可以动态分配索引节点：头顶上，至少Veritas VxFS（= HP-UX的默认文件系统，是Solaris上可用的选项之一）和XFS（RHEL 7上的标准文件系统类型）都可以工作那样。Btrfs和IBM的JFS也是如此。