FWIW, my own measurements tell a somewhat more complex story. Not hugely for reads, but writes. And less so for the higher end drives (with plenty fast cache).

FWIW, my own measurements tell a somewhat more complex story. Not hugely for reads, but writes. And less so for the higher end drives (with plenty fast cache). Plenty real world, write heavy, scenarios can benefit from having merging in positions other than head/tail (which noop can in the right circumstances). While FTLs are getting better and better, flash density is increasing (the number of QLC disks is growing, SLC ones are shrinking), and small writes are getting evermore expensive. This is especially bad for workloads involving fsync/O_DSYNC writes, because on drives with volatile caches they defeat all the efforts to shortish small write costby Of course there also a lot of write workloads that'd still never see merges, making a scheduler just unnecessary cost. This isn't helped by none of the current Linux schedulers really working well for local low latency storage. mq-deadline has completely antiquated heuristics and default constants, that clearly come from the spinning disk age. Bfq is too complicated (but works surprisingly well for higher latency / throttled storage). Nor helped by the fact that nearly every storage benchmark ensures that no merging ever will occur outside of "plugging" (basically sets of IOs submitted together). No wonder they never see any benefit from schedulers :(