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