Про ZFS prefetch (2)

Тесты интересные. Выводы, как по мне, не имеют право на жизнь :-). Видна явно аномально низкая скорость последовательного чтения при настройках по умолчанию. Предположу, что на шестидисковой конфигурации raidz2 средний размер запроса на чтения опять был в районе 32k и я так понимаю причина не найдена?

Вижу тебя продолжает беспокоить неравномерность загрузки дисков в raidz2, поэтому попробую разложить всё по полкам. Рассмотрим raidz2 из 7дисков, recordsize=1M, sectorsize=4k (ashift=12) и идеальный случай - на большом участке расположены только данные (метаданными пока пренебрегаем). Recordsize формируется так: на двух дисках контрольные суммы по 52х4k, на одном диске данные 52x4k и на четырех дисках - данные 51x4k. Получается у следующей recordsize контрольные суммы сдвинуты на три диска и так по кругу (для лучшего представления желательно нарисовать эту картинку на бумаге). Возврат контрольных сумм на исходные диски произойдёт через 7 recordsize (получается патерн расположения данных и контрольных сумм у каждого диска повторяется каждые 7 recordsize). Сам патерн имеет такую последовательность: контрольная сумма (52х4k), данные (51х4k), опять контрольная сумма (52х4k) и самый длинный непрерывный участок данных на диске - (51+52+51+51)х4k. Теперь оценим длину дорожки диска. Пусть в начале диска скорость чтения равна 180MB/s и скорость вращения 7200rpm, тогда информационная емкость дорожки в начале диска будет больше 180/120=1,5MB (больше потому что необходимо учитывать время перехода на следующую дорожку/цилиндр). Отсюда вытекает, что все диски при чтении будут задействованны, будут проходить все дорожки и вычитывать только ~71% (256/360) данных их общего количества данных на дорожке. Небольшой выигрыш видится только в случае, если контрольная сумма попадёт в конец дорожки и можно будет раньше начать переход на следующую дорожку/цилиндр, хотя и здесь есть сомнения. В итоге получаем, что верхний потолок скорости одного последовательного чтения на raidz2 из 7 дисков не будет превосходить 7*0,71*(скорость_самого_медленного_диска), то есть получили почти 5*(скорость_самого_медленного) и это в идеальном случае. На реальных данных должно быть ещё ниже :-(.
Теперь рассмотрим 6 дисков в raidz2. Ты наблюдаешь чтение только с 4 и значит верхний потолок не более 4*(скорость_самого_медленного) :-). Если происходит "не частое" смещение контрольных сумм и начинается чтение со всех дисков, то видно, что сумарная скорость чтения не изменяется :-). Поэтому всё аналогично.
Берём данные из таблицы твоего следующего поста и проверяем. Для raidz2 из 6 получаем скорость "самого медленного" 521/4=130MB/s и для raidz2 из 7 - 659/5=132MB/s. Всё сходится до +- погрешность, хотя в первом случае при чтении задействованы были 4 диска, а во втором 7 :-). Можно ещё предположить, что скорость рельного "самого медленного" WD1003FBYX была где-то на 10% выше.
Но у конфигурации из 6 есть "теоретический" ресурс. Если бы при записи смена дисков для контрольных сумм происходила для одного диска на величину больше длины дорожки (допустим 2MB), то можно было бы при соответствующем увеличении окна префетча задействовать все диски и получить условно "через-дорожечное" чередование. Это дало бы ощутимый прирост скорости последовательного чтения. В алгоритме балансировки зеркала в zfs применено "через-дорожечное" чередование, поэтому разработчикам известен этот приём и наверно есть весомые причины почему он не применён в некоторых подходящих конфигурациях raidz, хотя кто его знает ;-).
Вот как то так.