On Wed, Nov 30, 2011 at 11:18:42AM +0100, Jens Axboe wrote: > I agree on a+b, but c is definitely more than debatable. I have yet to > see a device saturate its bandwidth on 4KB IOS. So merging on the write > side is always going to be a win. We shouldn't submit 4k I/O in the first place unless they truely are random. If you look at XFS for example you'd basically never see them. The only small I/O in a typical workloads are individual btree blocks and AG header updates, which generally can't be merged anyway. Data I/O happens in larger chunks generally, as do reads/writes of inodes (generally in 32k chunks, with plans to go larger). Note that the merges in the way the are done currently are one of the most painful bits of the current request_fn based drivers. They require the addition of the struct request data structure, which needs to be allocated and initialized for every bio, no matter if it's beeing merged or not, and are the prime reason why make_request_fn and request_fn style drivers can't operate on the same data structures. I've been wondering if it would be possible to simply chain bios for merging, and while it's theoretically possible I'm wondering about the impact on drivers. Fortunately scsi drivers generally don't touch struct request directly, so it might be doable. -- To unsubscribe from this list: send the line "unsubscribe linux-scsi" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html