> Неужели в Linux только сейчас начали избавляться от зависимости планирования дисковых операций
> от аппаратных особенностей усройств хранения? Во FreeBSD например, судя по книжке
> "Архитектура и реализация", в GEOM намеренно отказались от учёта физических параметров
> винчестеров, таких, как время перемещения головки. Поэтому там достаточно примитивный
> планировщик I/O, которому в общем-то по барабану, с каким накопилем он
> работает — с HDD или SSD.

Ему вообще-то не совсем по барабану. Потому что если, например, для диска лифтовый шедулер знает, что сейчас мы пишем блок 1000, в очереди стоит блок 990 от низкоприоритетного процесса, текущее направление лифта - вниз, а поступил заказ на блок 2000 от высокоприоритетного процесса - то шедулер должен решить, достаточно ли новый заказ важен, чтобы сбить логику лифта и погнать его срочно вверх (на 2000), или можно продолжить проход вниз (где ждёт 990) и заставить высокоприоритетный процесс таки подождать. В целом мы будем иметь суммарный вес заказов на текущее направление движения и суммарный вес заказов на перебой направления. TQ и NCQ слегка устраняют эти проблемы, при условии, что текущая очередь не превышает их предельной глубины очереди (до 255 у SCSI TQ и до 31 у NCQ), но если заявок больше, то всё равно приходится начинать думать. А для SSD это всё не имеет никакого значения, всё равно не угадаешь, что там внутри в текущую минуту как разложено. Особый цимес конструированию шедулеров придают задачи обеспечения одновременно скорости важного потока и периодических мотаний туда-обратно головками для других важных операций... в общем тут можно полировать и вылизывать годами.

Когда Вы говорили про время перемещения головки, вспоминали особенности старых дисков (грубо говоря, до времён PC, а вместо этого на PDP-11 или аналогах), которые были особо медленными, зато можно было угадать, что вот прямо сейчас мееедленно подползает блок 2 на дорожке. Да, с введением внутренних трансляций геометрии, мультизонных дисков с разной плотностью (это где-то от рубежа 400MB) это всё потеряло смысл окончательно, сейчас по LBA невозможно установить, в какой момент надо подавать какой блок на запись. Можно только предсказать положение головок, и это работает надёжно, по крайней мере пока нет ремапов. А при TQ и NCQ - весь текущий пул запросов будет отработан диском. Но, как я описал выше, это далеко не все проблемы.

Упрощение в FreeBSD по текущему моменту вызвано фактически тем, что у операций I/O нет приоритета, который бы каким-то образом вычислялся из приоритета их заказчика. Если их введут, то придётся снова серьёзно думать о выборе шедулера.