我目前正在使用backintime拍摄我的文件系统的“快照”。它类似于rsnapshot其中，对未更改的文件建立硬链接。我的文件系统上的索引节点最近用完了EXT4。df -hi显示我已经使用了 940 万个索引节点。粗略计算当前目录的数量乘以快照的数量加上当前文件的数量表明我实际上可能使用了 940 万个 inode。
据我了解，EXT4文件系统可以支持大约 2^32 个 inode。我正在考虑重新格式化分区以使用全部 40 亿个左右的索引节点，但我担心这是一个坏主意。文件系统中拥有如此多的索引节点有什么缺点EXT4？对于这样的应用程序，是否有更好的文件系统选择？
答案1
这是一个非常糟糕的主意。每个 inode 消耗 256 字节（可以配置为 128）。因此仅 inode 就会消耗 1TiB 的空间。
其他文件系统（例如 btrfs）可以动态创建 inode。请改用其中之一。
答案2
我真的无法强调这一点，不要创建大量的索引节点！
首先，您的fsck运行时间可以呈指数级延长，尽管其中一些问题已在 ext4 中得到解决。更重要的是，索引节点并不是唯一限制文件数量的因素，可能不可能使用所有这些索引节点。这不仅是实际上，而且在技术上实际上也是不可能的。
mkfs 手册页摘录，
-i bytes-per-inode 指定字节/inode 比率。 mke2fs 为磁盘上的每个 inode 字节空间创建一个 inode。每个 inode 的字节数比率越大，创建的 inode 就越少。该值通常不应小于文件系统的块大小，因为在这种情况下，将创建比可以使用的更多的 inode。请注意，文件系统创建后无法扩展其 inode 数量，因此请谨慎确定此参数的正确值。
当创建 OP 新文件系统时，实际上，OP 应该开始计算每个 inode 的最大字节数 = 块大小......对于稍后阅读本文的每个人来说，OP 有一个非常不寻常的情况，他有大量文件。