Как уже сказали, зависит от роли сервера (или приложений, которые там будут), если это для чего-нибудь потокового - то лучше больший размер, если это файловое и сиквельное - то ставят обычно 64-128

авторА raid10 из 8 дисков это как?
4 в страйпе, 4 их зеркалируют

авторНет, вовсе не то же самое. У него собраны два страйпа по 4 диска, и только потом они зазеркалены. В твоей схеме созданы 4 зеркала, которые потом собраны в страйп.
Вторая схема разумнее. При выходе из строя одного диска и его замене ребилдиться будет двухдисковое зеркало, а при первой схеме - весь восьмидисковый страйп.
На текущий момент, ни один контроллер, энтерпрайз СХД мы тут не берем в расчет, не позволяет Вам выбирать между зеркалом страйпов и страйпом зеркал, так что в любом случае в CLI или графическом интерфейсе будет указан рэйд 10 и все. Так что все рассуждения, как лучше сводятся только к наличию хот-спаре и ЗИП

авторХочется максимально увеличить скорость записи данных на созданный массив. На сервере будет установлено Srv1012 + SQL2012 + 1C-сервер. Делаю так после создания массива RAID 10 - делю его на 3 виртуальных диска. 1 (под систему) указываю stripe-64Kb, 2 (под SQL базы) указываю stripe-32Kb, 3 (под файлы) указываю stripe-64Kb. Вопрос был такого характера, КАК НАИБОЛЕЕ правильно определить stripe для дисков.
Размер страйпа (блока) указывается для всего рэйд-массива, для LUN нельзя его было устанавливать (было так по крайней мере), ставьте 64, будет нормально. Для записи будет важно наличие энергозащищенной памяти, если такую возможность предоставляет контроллер, ну и приоритет распределения кэша контроллера, правда это тоже уже редкость(

авторТо есть я должен поверить твоим словам и не поверить тому, что вижу не первый год? до сих пор помню, как генерил сперва три зеркала, а потом объединял их в страйп, хоть и 6 (или 7?) лет прошло - доков под рукой не было,
Я могу охотно поверить, но смысл в том, что те времена, когда можно было что-то конфигурить уже прошли. Сейчас мало выбрать что-то для себя, максимум можно судить по названию рэйда 0+1 или 1+0, а все остальное - процент разделения кэша на чтение\запись, выбор страйпа зеркал или зеркала страйпов, да даже без энергозащищенности памяти частенько нельзя включить кэш на запись - я говорю это про Intel-LSI c их Mega-ServeRaid, PERC и так далее, PMC-Adaptec уже не встречается в серверах. Тут все зависит от прошивок и степени параноидальности вендора.

авторВо-первых, из-за надежности. См. habrahabr.ru/post/78311/ статья старая, но более-менее годная.
Тут все спорно. ибо и память в рэйд-контроллере с коррекцией ошибок, и SAS диски обладают механизмом коррекции ошибок в отличие от десктопов, плюс к этому после сбойных попыток чтения\записи переназначают сектора, плюс при ухудшении параметров предварительный ребилд уже идет (но это если вендора с их прошивками). Поэтому по факту ошибок и не видно или ребилд происходит достаточно быстро.
А считать тер.вер, ну так по ней я и динозавра могу встретить сейчас в квартире, но исходя из реалий, этого не будет)
Поэтому, я бы выделил два варианта:
1) Отдать все под 10 рэйд
2) 6 дисков в 10 рэйд, 1 - горячая замена, 1 в ЗИП
Варианты зависят от наличия бэкапов, контрактов, простоев, наличия ЗИП и параноидальности)
Нарезка LUN по усмотрению
автор2 - в raid1 под OS и приложение / (ну и бэкап, если что)
4 - в raid10 под данные
2 - в raid1 под wal
Меньшая производительность массива по шпинделям, при наличии энергозащищенной памяти (а сейчас она уже мин 512МБ идет) контроллер сам сбрасывает в зависимости от загруженности дисков данные (включая и то. над каким сектором или блоком проходит диск или будет проходить), так что результат будет хуже, если делить, исключение постоянная большая потоковая запись лога СУБД.

авторВо-вторых, проблема в ошибках, которые проходят через эту коррекцию незамеченными. Т.е. записали в сектор одни данные, прочитали другие, ошибки не возникло.
Аппаратные контроллеры могут запросить аналогичные данные и с другого жесткого диска или в массиве состоят, или же, если данные еще в кэше сравнить с ним, в том числе и контрольную сумму.
Для просто проверок секторов и прочего рэйд-контроллер время от времени осуществляeт patrol read

авторТогда как речь о необнаруженных ошибках.
Для этого как раз и существует Patrol Read которые запускается по расписанию, которое задается или дефолтное раз в неделю.
Для ошибок логики существует ЕСС, в десктопных винтах его, кстати, нет.
авторЕсли данные в кэше, то с диска их вообще читать никто не будет. Тем более, что размер кэша на порядки меньше размера диска.
Это, если хотите, маленький аудит со стороны контроллера вида: "а не сверю ка ли я?" Понятно, что все не будет шерстить, но точечно возможно, как раз такие оптимизации и делаются вендорами, а не тупо: пиши, что хочешь, траблы потом увидим..
автор'Как оценить влияние потока записи лога СУБД'
Логично, что счетчиками Perfmon, если позволяет утилита к контроллеру, то и ее задействовать.
авторгде на запись - данные малого объема, но часто...
Смотрятся показания счетчиков монитора производительности, анализируются. В большинстве случаев энергозащищенной памяти достаточного объема хватает, чтобы по мере загруженности дисков раскидывать данные на запись. Но надо и смотреть загрузку на чтение, она тоже важна, плюс скорость дисков влияет.

авторИ что же сделает этот Patrol Read, если обнаружит, что данные в массиве некорректны? исправить-то уже неоткуда...
Вы не совсем правильно поняли, Patrol Read должно проверять блоки, при ухудшении параметров, оно сообщает контроллеру и переносит данные. Понятно, что может случиться такая ситуация, когда блок внезапно стал нечитаемым, но для этих случаев есть повторные попытки, вплоть до снижения скорости. Я уж не говорю о тех случаях, когда при ухудшении параметров производится предварительный ребилд, дабы сократить время (хотя вроде говорил)
Но Patrol Read нужно проводить. а многие администраторы это игнорируют, причем у этой функции есть и опции (вплоть до реал тайма, записано - проверено, сравнено с кэшем)
Правда это касается фирменных прошивок вендоров, часть реализовано и в стандартном виде у Intel+вендоры HDD
авторЕсть. И более того, с переходом на 4-килобайтовые сектора объем служебной информации для ECC был увеличен
Стандартно - да, но если вы посмотрите различие в логике (не только механике) SATA vs SAS, то вы поймете.

авторЭто вы меня не поняли. Еще раз повторяю - речь о необнаруженных на уровне HDD ошибках. При этом HDD не рапортует об "ухудшении параметро" или чем-то подобном.
Ок, я не буду спорить, в случае серверного железа с рекомендуемыми настройками подобные ошибки "вдруг" будут сведены к минимуму.
Ваши аргументы "вдруг" приравниваются к:
- я херакнул кувалдой по серверу, почему жесткие диски не работают
- у нас прорвало каналию все вылилось на сервер, жесткие диски опять не работают.
Сценарии можно продлить. от внезапности Вас ничто не спасет, но шансы на эту внезапность сократят. Прочитав любой документ (whaitepaper, redbook, knowledgebase), всегда будет сказано - имейте актуальный бэкап!
Что Вам еще сказать?

miksoft,
Не пойму я Вас:
то вы говорите о
авторЕще раз повторяю - речь о необнаруженных на уровне HDD ошибках. При этом HDD не рапортует об "ухудшении параметро" или чем-то подобном.
то сразу переводите на
авторв подавляющем числе случаев они могут быть обнаружены и скорректированы алгоритмами ECC еще до передачи данных по интерфейсу во внешний мир. Значительно реже они могут быть обнаружены, но не скорректированы. Еще реже они не могут быть даже обнаружены.
Так о каких ошибках мы все же говорим? К тому же я писал об алгоритме восстановления ошибок, если они не читаемы с определенного блока

авторА изначально речь о другом виде ошибок - которые даже не обнаруживаются алгоритмами контроля и восстановления.
Из практики, я не привожу тут тер.вер., я не встречал, хотя работал в очень крупных датацентрах. Если дохнет, то весь винт сразу. реже, когда сдох блок на винте, но и в этом случае, можно по контрольным суммам восстановить его.
Еще раз скажу, что используя адаптивные прошивки и регламентные операции, практически все это сводится к нолю, теоретически нет - но на это должны существовать бэкапы.