我已经查看过有关 inode 使用、安装问题和其他问题的其他问题/答案，但这些问题似乎都不适用......
DF-H
/dev/sdd1 931G 100G 785G 12% /媒体/teradisk
DF-IH
/dev/sdd1 59M 12M 47M 21% /media/teradisk
基本上，我有一个 1TB 大小的 EXT4 格式的驱动器，并且正在将大约 1200 万 (12201106) 个文件写入一个目录。我找不到任何关于 EXT4 每个目录文件数限制的文档，但文件系统报告没有剩余空间。
奇怪的是，我仍然可以在驱动器和目标文件夹上创建新文件，但是在执行大型 cp/rsync 时，调用mkstemp并rename报告设备上没有剩余空间。
rsync：mkstemp“/media/teradisk/files/f.xml.No79k5”失败：设备上没有剩余空间（28）
rsync：重命名“/media/teradisk/files/f.xml.No79k5”->“files/f.xml”：设备上没有剩余空间（28）
我知道出于很多原因，不建议将这么多文件存储在一个目录中，但除非我能帮助，否则我不希望将它们分开。
tmpfs、设备和其他一切的 Inode 和空间使用情况看起来都很好。有什么原因吗？
答案1
这XFS 文件系统对于您现在正在尝试做的事情来说，这将是一个更可支持的（长期）解决方案。文件数大的目录对 XFS 来说不是问题。当然，在应用程序级别修复这个问题也会有所帮助...
答案2
似乎您已经达到目录大小限制。目录本身是某种特殊文件，其中包含其中所有文件的名称（+ inode 编号以及可能的其他元数据）。并且它不能大于 2G。
无论如何，在一个目录中拥有超过几千个文件并不是一个好主意：按文件名搜索会非常慢，并且在使用 ls、rm 等标准工具时会遇到很多问题。
更新：
啊哈！
http://old.nabble.com/re:文件夹下文件的最大数量-td16033098.html
2008 年 3 月 13 日 13:23 -0400，Theodore Ts'o 写道：
文件夹中的文件数量没有限制，但目录本身不能大于 2GB，并且整个文件系统可用的 inode 数量也不受限制。当然，如果您没有打开目录索引，您可能不喜欢目录查找的性能，但那是另一回事。
当前 ext3 htree 代码还限制深度只有 2 级。除了 2GB 的限制外，在 15M 左右的文件上会遇到问题，具体取决于文件名的长度。
答案3
ENOSPC使用文件系统时的另一个错误来源ext4可能是所使用的目录索引哈希算法的哈希冲突。
这博客文章谈论更多细节：
ext4 使用 half_md4 作为默认哈希机制。如果我正确解读了 google 搜索结果，则它使用 md4 哈希算法，但将其精简为 32 位。这是生日悖论的一个经典示例：32 位哈希意味着有 4294967296 个不同的哈希值可用，因此如果我们公平地假设哈希值分布均匀，则命中一个特定哈希的可能性极小。但是，如果文件名足够多，命中两个相同哈希的概率要高得多。使用 Wikipedia 中的公式，我们得到（约 50K 个文件）新添加的文件具有相同哈希的概率约为 25%。这是一个巨大的失败概率。另一方面，如果我们采用 64 位哈希函数，概率就会变得小得多，约为 0.00000000007%。
将目录哈希算法更改为应该tea可以解决问题。
答案4
我遇到了这个问题。我的解决方案是：
mkfs.ext4 -i 1024 -b 1024 /dev/blah