我的Linux使用Deadlinealgorithm进行I / O调度。 其中一个参数是/sys/block/sda/queue/iosched/front_merges下的front_merges参数。 默认情况下它被设置为1，这意味着前面的合并很可能发生。 如果不希望前端合并发生，可以将其设置为0来获得性能提升。
内核文档说得最好：
有时会发生请求进入与已经在队列中的请求连续的io调度器。 它可以放在请求的后面，也可以放在前面。 这被称为回合候选人或前合并候选人。 由于文件通常布局的方式，反向合并比前面的合并更加普遍。 对于某些工作负载，您甚至可能知道花费任何时间尝试前置合并请求是浪费时间。 将front_merges设置为0将禁用此function。 由于caching的last_merge提示，前端合并可能仍然会发生，但是由于基本上为0，所以我们将其保留。 当io调度程序合并函数被调用时，我们只需禁用rbtree前台扇区查找。
前面合并的原因并不常见，作家通常不会以相反的顺序将数据块写入磁盘。
考虑一个简单的顺序写入包含两个块的新文件的过程。 它首先写入数据块0，然后写入数据块1.当数据块1碰到队列时，它位于数据块0的后面，这样内核就会进行回合，然后同时将两个数据块发送到物理磁盘。 这是典型的情况。
为了获得前端合并，该过程首先必须写入块1，然后向后寻找并写入块0.这不是典型的情况，尽pipe对于某些工作负载（例如，数据库）而言。
即使在高I / O的情况下，我也不希望性能的变化在这里很重要。 你可以在你的实际工作量上进行两种testing。 如果你没有使用磁盘密集型的东西，那么这并不重要。
红帽说：
front_merges：如果您知道您的工作负载永远不会生成前端合并，您可以将此可调参数设置为0。 除非您已经测量了此项检查的开销，否则build议将其保留为默认设置（1）。
所以推荐的设置是默认离开。 我可以告诉你，我通常不会在调整过程中修改这个设置，但这取决于你的工作量。
请参阅： Linux – 真实世界的硬件RAID控制器调整（scsi和cciss）
最好的方法是采取科学的testing你的数据，系统和环境。
您可以使用iostat -x命令监视合并活动，并跟踪输出中的rrqm/s和wrqm/s字段。 这些列中的任何非零值表示连续请求在被传送到底层存储之前已合并。 这也表明工作量是连续的。
如果在这些列中没有看到活动，那么修改截止datefront_merge可调参数将不会使您受益。
您在有关服务器types或存储子系统的问题中没有提供任何真实的细节。 如果您使用任何types的具有caching的硬件RAID或某些文件系统，则会考虑此可调参数的影响。