ну у тебя же идёт как. fio -> ядро -> драйвер СХД -> очередь тома
таким образом если даже в fio 4 потока и в ядре 4 очереди (blk-mq), а в драйвере СХД 1 поток - то запросы из 4 потоков fio просто сольются в 1 поток
то что ты говоришь по разным ядрам - это не шедулер, а blk-mq (шедулер только запросы переставляет/мержит)
и при этом как я понимаю кроме NVMe / NVMeoF НЕТ интерфейсов, которые бы умели несколько очередей, поэтому фактически всегда такая ситуация что запросы к 1 тому сливаются в 1 поток
все верно, только не в один поток, а в одну очередь). но надо помнить что у схд есть фронтенд, задача которого максимально быстро отдать ack в потребителя и есть внутренняя логика распределения записи по лунам и по дискам. если на фронтенд подать один поток с одного хоста (один экземпляр fio) - то мы упремся в глубину очереди блочного устройства, HBA на уровне хоста. поверь глубина очереди на лун, в случае enterprise сеегмента схд, существенно больше чем на уровне хоста. поэтому схд в приведенном мной случае окажется ненагруженной. плюс есть схд (например трипар) которые могут прогрузить все ядра даже при использовании одного луна. но опять же, подав один поток с fio (с любым значением глубины очереди) на трипар ты не прогрузишь на 100%. другими словами при таком тесте ты не увидишь максимально возможного уровня производительности схд.
