Дай угадаю, а /dev/md127p2 еще медленнее? (Причем, чем больше p1, тем больше разница.)
Это специфика hdparm (проявляется в зависимости от фазы луны).

Скорость на пятых-шестых софтовых рейдах вообще сильно зависит от модели проца и общей нагрузки на систему. Чем быстрее и проц и меньше нагрузка — тем быстрее рейд.

Советую потюнить по этому гайду.

И мерить уже по скорости работы фс в разных режимах, а не в hdparm'овских абстрактных попугаях.

hdparm не может служить объективным тестом, он не предназначен для работы с чем-то, кроме физических устройств.

Хз. Я дальше p1 не забирался, просто удивился. Почему-то думалось, что hdparm просто читает с устройства и пишет результат. Не понятно, откуда разница берётся. Да, кстати, судя по top'у, при чтении с p1 проц занят в 2 раза меньше, чем на прямую с диска. Тоже не понятно.

hdparm не может служить объективным тестом, он не предназначен для работы с чем-то, кроме физических устройств.

Почему hdparm -t не может быть тестом на скорость чтения с устройства?

Почему hdparm -t не может быть тестом на скорость чтения с устройства?

Да потому что врёт нагло. Я это заметил на dm-crypt. dd и pv показывали верный результат, а hdparm — в несколько раз меньше.

Стоп. О каком устройстве речь? Если /dev/sd? напрямую, то всё нормально, а вот если софтовый рейд или что подобное, то тут уже не стоит безоговорочно полагаться. dd лучше используй.

dd и pv показывали верный результат, а hdparm — в несколько раз меньше.

У меня показания dd и hdparm согласуются не плохо, т.е. это не просто лажа hdparm, dd подтверждает.

а вот если софтовый рейд или что подобное, то тут уже не стоит безоговорочно полагаться. dd лучше используй.

Именно софтовывй, но показания dd и hdparm практически совпадают. И это странно.

Именно софтовывй, но показания dd и hdparm практически совпадают. И это странно.

Ну, если совпадают, то всё верно.

Ну, если совпадают, то всё верно.

Угу. Тогда почему /dev/md127 показывает 60 Мбайт/c, а /dev/md127p1 - 35?

А диски случаем не с 4К секторами?

А диски случаем не с 4К секторами?

Да не должны. Seagate 7200.[7,9] на 80 и 120 Gb. Да и сами-то диски более-менее адекватны. Вопрос в том, что сам raid читается нормально, а раздел на на нём - в 2 раза медленнее.

32 - это слишком быстро для RAID5 на трех дисках

Потюнить, поапргейдить.

Советую потюнить по этому гайду.

Советую не использовать программный RAID-5, грузит ЦП. Но это, вообще-то, тема для другого обсуждения, потому что у вас RAID-5 уже используется во всю.

32 - это слишком быстро для RAID5 на трех дисках

Да? Почему на линейном чтении большого куска 32 - это много?

Советую не использовать программный RAID-5, грузит ЦП

Если верить top'у, то чтение с raid'а в 2 раза меньше грузит проц, чем просто с диска.

Если верить логике.

Если верить top'у, то чтение с raid'а в 2 раза меньше грузит проц, чем просто с диска.

Странненько. Ведь при чтении с трёхдискового массива нужно прочитать в полтора раза больше данных, да ещё произвести с ними некие математические манипуляции, а результат их проверить.

Странненько.

Очень.

да ещё произвести с ними некие математические манипуляции, а результат их проверить.

XOR? Ну не такая уж и страшная математика :)

Что-то мне думается что при чтении XOR не делается, да и зачем. Чтобы проверить целостность данных? Это не поможет, т.к. неизвестно какой из дисков лажает. XOR делается при записи, хотя могу ошибаться. Так что нет там никакой математики, что-то с настройками я думаю.

что-то с настройками я думаю.

Какие настройки уменьшают скорость чтения с раздела, созданного на raid'e, вдвое в сравнении с самим raid'ом?

Не знаю. Я вообще никогда на рейдах не делал разделов :) Я делал наоборот - создавал разделы и делал из них рейд. Но вообще конечно выглядит крайне странно. Кстати, зачем вообще создавать раздел, если он и так один? Делай ФС прям на рейде.

Кстати, зачем вообще создавать раздел, если он и так один?

Вот сейчас меня терзает тот же вопрос. Нафига мне это было надо? :)

наноXOR.

XOR? Ну не такая уж и страшная математика :)

Не страшная, но контроллер специально заточен вычислять XOR, быстро, решительно. Без всяких там длинных конвейеров и прочего. Я обычно исхожу из положения, что специализированное устройство (в данном случае микросхема контроллера) должно справляться с задачей лучше универсального (хотя универсальное, в данном случае, может стоить на порядок больше специализированного).

Ещё одно соображение, учитывая возможности современных процессоров и НЖМД, а так же ТТН, можно ли говорить, что контроллеры практически различаются только количеством портов, а характеристики их микросхем не столь важны, поскольку разумно использовать программный RAID?

Не страшная, но контроллер специально заточен вычислять XOR, быстро, решительно. Без всяких там длинных конвейеров и прочего.

Ну да. Но, по-моему, скорости HDD не достаточно, чтобы разница с CPU в этом плане стала сильно заметной.

Я обычно исхожу из положения, что специализированное устройство (в данном случае микросхема контроллера) должно справляться с задачей лучше универсального (хотя универсальное, в данном случае, может стоить на порядок больше специализированного).

А может, просто цена на универсальное слишком высока и потому просто дешевле специализированное, но простое поставить?

Ещё одно соображение, учитывая возможности современных процессоров и НЖМД, а так же ТТН, можно ли говорить, что контроллеры практически различаются только количеством портов, а характеристики их микросхем не столь важны, поскольку разумно использовать программный RAID?

Не везде и не всегда, имхо, но зачастую именно так.