My Linux uses the Deadline algorithm for I/O scheduling. One of the parameters is the front_merges parameter under /sys/block/sda/queue/iosched/front_merges. By default it is set to 1, which means front merges are likely to occur. One can set it to 0 to gain a performance boost if don't expect front merges to occur.
The kernel documentation says it best:
Sometimes it happens that a request enters the io scheduler that is contiguous with a request that is already on the queue. Either it fits in the back of that request, or it fits at the front. That is called either a back merge candidate or a front merge candidate. Due to the way files are typically laid out, back merges are much more common than front merges. For some work loads, you may even know that it is a waste of time to spend any time attempting to front merge requests. Setting front_merges to 0 disables this functionality. Front merges may still occur due to the cached last_merge hint, but since that comes at basically 0 cost we leave that on. We simply disable the rbtree front sector lookup when the io scheduler merge function is called.
The reason front merges are uncommon is that writers typically do not write blocks to disk in reverse order.
Consider a process which does a simple sequential write of a new file containing two blocks. It first writes block 0, then writes block 1. When block 1 hits the queue, it is in the back of block 0, so the kernel does a back merge, then sends both blocks to the physical disk at the same time. This is the typical case.
To get a front merge, the process would first have to write block 1, then seek backward and write block 0. This isn't the typical case, though for some workloads it does happen (e.g. databases).
I wouldn't expect the change in performance to be that significant here, even with high I/O. You can test it both ways on your actual workload. If you aren't doing something disk intensive, then this isn't really important.
Red Hat says:
front_merges: You can set this tunable to 0 if you know your workload will never generate front merges. Unless you have measured the overhead of this check, it is advisable to leave it at its default setting (1).
So the recommended setting is to leave at default. I can tell you that I don't usually modify this setting in my tuning efforts, but it depends on your workload.
See: Linux - real-world hardware RAID controller tuning (scsi and cciss)
Also the best approach is to take a scientific one in testing with your data, systems and environment.
You can monitor merge activity using the iostat -x command and tracking the rrqm/s and wrqm/s fields in the output. Anything that's not a ZERO in those columns indicates that contiguous requests were merged before being delivered to your underlying storage. This also indicates that the workload is sequential.
If you don't see activity in those columns, modifying the deadline front_merge tunable won't benefit you.
You didn't provide any real details in your question about the server type or storage subsystem. If you're using any kind of hardware RAID with caching, or certain filesystems, they factor into the impact of this tunable parameter.
