Dan*_*nny 7 filesystems ext4 ext3
我们的应用程序将数据写入磁盘作为一个巨大的环形缓冲区（30 到 150TB）；删除旧文件的同时写入新文件。因此，根据定义，磁盘总是“接近满”。
该作家过程在约100-150兆比特的净输入速度创建各种文件/秒。数据文件是 1GB 的“数据”文件和几个较小的元数据文件的混合体。（输入速度是恒定的，但请注意新文件集每两分钟只创建一次）。
有一个单独的删除程序，它每 30 秒删除一次“最旧的”文件。它会不断删除，直到磁盘上达到 15GB 的可用空间。
所以在稳定运行时，所有数据分区只有 15GB 的可用空间。
关于这个与文件系统减速有关的问题，DepressedDaniel评论道：
同步挂起只是意味着文件系统正在努力工作以一致地保存最新的操作。在那段时间里，它肯定是在尝试在磁盘上打乱数据。我不知道细节，但我很确定如果你的文件系统严重碎片化，ext4 会尝试做一些事情。如果文件系统几乎 100% 已满，那就不好了。以接近 100% 的容量利用文件系统的唯一合理方法是使用一些文件对其进行静态初始化，然后覆盖这些相同的文件（以避免碎片化）。可能最适合 ext2/3。
ext4 是这个应用程序的糟糕选择吗？既然我们是实时运行的，那么可以对 ext4 进行哪些调整以避免碎片化、速度变慢或其他性能限制？从 ext4 更改将非常困难......
（重写静态创建的文件意味着重写整个应用程序）
谢谢！
编辑我
该服务器连接了 50 到 100 TB 的磁盘（24 个驱动器）。Areca RAID 控制器将 24 个驱动器作为 RAID-6 RAID 集进行管理。
从那里我们分成几个分区/卷，每个卷是 5 到 10TB。所以任何一卷的大小都不是很大。
“writer”进程找到具有“足够”空间的第一个卷并在那里写入一个文件。写入文件后，重复该过程。
对于全新的机器，卷是按顺序填满的。如果所有卷都“已满”，则“删除程序”进程开始删除最旧的文件，直到“足够”可用空间。
在很长一段时间内，由于其他进程的作用，文件的时间顺序在所有卷中随机分布。
编辑二
运行fsck显示非常低的碎片：1 - 2%。然而，在此期间，缓慢的文件系统访问已追踪到各种系统调用一样fclose()，fwrite()，ftello()等走了很长的时间来执行（5到60秒！）。
至今没有解决这个问题的办法。在这个 SO 问题中查看更多详细信息：如何调试非常慢（200 秒）fwrite()/ftello()/fclose()？
我已经禁用sysstat，raid-check看看是否有任何改进。