今天遇到了一个有我疑惑的服务器的情况。 这是一个场景：
系统日志显示：
内核：EXT3-fs警告（设备sdb2）：ext3_dx_add_entry：目录索引已满！
发现罪魁祸首是一个有910万个文件的目录。 我知道这是900万个文件，因为我用它来删除它们：
perl -e 'my $i=0;for(<*>){$i++;((stat)[9]<(unlink))} print "Files deleted: $i\n"' 完成后，我跑了ls – 大约花了3分钟，并返回了1个文件。
几分钟后，一批新的 – 又有910万个文件出现在同一个目录中，syslog再次显示：
内核：EXT3-fs警告（设备sdb2）：ext3_dx_add_entry：目录索引已满！
我再次运行删除，完全相同的情况重演。 几分钟后，新一批超过900万的文件。
刚刚出现的文件是旧的（约3个月大）。
有人可以确认这是否是ext3的预期行为？
我怀疑这是怎么回事，但我目前没有任何证据。
任何反馈赞赏！
请注意这个问题不是关于如何解决这个问题，而是关于理解这里发生的事情。
“ …这个问题不是关于如何解决这个问题，而是关于理解这里发生的事情…… ”
我的猜测是你正在遭受（严重的）文件系统损坏，越多的文件将被创build和删除，越严重的损坏将会发生。
我说这是因为：
你写了“ …几分钟后又有910万个文件出现在同一个目录中…… ”。 我们假设用“几分钟”，你打算15分钟。 这意味着每秒创build大约10K个文件。 即使你的服务器/存储能够承受这样的负担，很难相信在这样的创build过程中， 没有任何这样的活动的迹象！ 所以，至less有两个事实：
让我想一下……创build过程是“假的”，因此，你有文件系统的完整性问题;
即使是强硬的消息“ ext3_dx_add_entry：目录索引已满！ ”让我觉得在这种情况下，应该不可能在相关的文件系统中创build额外的文件（顺便说一下，如@Stefan所述，评论你的操作系统），似乎是能够有效地创build额外的文件。 这又是 – 恕我直言 – 另一个事实提高注意力。 作为一个部分的缓解措施，日志消息（EXT3-fs警告）中的“ 警告 ”一词（…而不是“错误”）使我认为即使是内核开发者也期望这种情况不是这样“批评”（…他们认为这是一个警告…而不是一个错误，所以它不应该是这样的…太可怕了！
除此之外，我还发现这个其他的顺丰邮政确认，至less是那个具体情况，问题是文件系统完整性问题。
至于你的问题的最后一部分（与“caching”假设有关的问题），即使我根本不是内核黑客，我坚信这不是内核行为，因为它会超出范围的内核，是要跨模块接近的东西（不可能实现只处理ext3模块）。 但是，请不要怪我，如果这最后一句话是绝对错误的！ 这只是我的“感觉”:-)
至于上面的第二点），我错了 ：“目录索引”似乎并不是与用来有效存储文件数据和文件元数据的文件系统结构严格相关的。 相反，它只是一种优化在包含大量文件的目录中查找的手段[请参阅此处或此处其他SF文章] 。 这似乎解释了为什么日志会报告“警告”（而不是“错误”），因为在我看来，“目录索引”已满时，一切都可以照常进行，而没有索引的好处。