上周我遇到了一个问题（对我来说是新问题）。我有一个 ext4 (Fedora 15) 文件系统。服务器上运行的应用程序突然停止了。乍一看没发现问题。
df显示 50% 可用空间。搜索了大约一个小时后，我看到了一个论坛帖子，该人使用了df -i.该选项查找 inode 的使用情况。系统没有索引节点，这是一个我没有意识到的简单问题。该分区只有 3.2M 索引节点。
现在，我的问题是：我可以让系统有更多的索引节点吗？格式化磁盘时应该/可以设置吗？使用 3.2M inode，我可以有多少个文件？
答案1
您的文件似乎比正常预期多得多。
不知道有没有办法动态改变inode表大小。恐怕您需要备份数据、创建新的文件系统并恢复数据。
要创建具有如此巨大的 inode 表的新文件系统，您需要使用 mke2fs(8) 的“-N”选项。
我建议首先使用“-n”选项（它不会创建文件系统，但显示有用的信息），以便您可以获得估计的索引节点数。然后，如果需要，请使用“-N”创建具有特定 inode 编号的文件系统。
答案2
有了 320 万个 inode，您总共可以拥有 320 万个文件和目录（但到一个文件的多个硬链接仅使用一个 inode）。
是的，可以在分区上创建文件系统时设置。选项-T usage-type、-N number-of-inodes、 或-i bytes-per-inode都可以设置 inode 的数量。我通常在比较类似文件集合的和-i的输出并允许一些松弛之后使用 , 。du -sfind | wc -l
不，它不能在现有文件系统上就地更改。然而：
- 如果您正在运行 LVM 或文件系统位于 SAN 的 LUN 上（直接位于 LUN 上，或作为 LUN 上的最后一个分区），或者分区后磁盘上有空闲空间，则可以增大分区，然后用于
resize2fs扩展文件系统。这大致会按照增加的空间的比例添加更多的索引节点。如果您想避免在空间之前耗尽 inode，假设未来的文件平均大小大致相同，请使用 来设置足够高的保留块百分比tune2fs -m。 - 如果您有足够的空间并且可以使文件系统脱机，则将其脱机，创建一个具有更多 inode 的新文件系统，然后复制所有文件。
- 如果只有一个文件子集使用大量 inode，并且您有足够的可用空间，请在文件系统上的文件支持的循环设备上创建一个文件系统，创建一个具有更多 inode 的文件系统（也可能是更小的块）并将有问题的目录移入其中。这可能会影响性能并带来维护麻烦，但它是一种替代方案。
- 当然，如果您可以删除大量不需要的文件，那也会有所帮助。
答案3
作为另一种解决方法，我建议考虑将大量文件打包到未压缩的（！）tar存档中，然后将archivemount其挂载为文件系统。 tar 存档比文件系统映像更适合共享，并且在备份到云或其他存储时提供类似的性能。
如果集合应该是只读的，squashfs可能是一个选项，但它需要在内核中启用某些选项，并且xz压缩也可用于 tar 并具有相同的性能。
答案4
尝试将du -s --inodes * 2>/dev/null |sort -gcd 插入输出中的最后一个目录并重复。
全面披露：并非所有操作系统都支持--inodesdu 命令（我的 Mac 操作系统不支持），但许多 Linux 操作系统都支持。