Важно! Перед любыми операциями с массивами бэкап важных данных обязателен!
В теме обсуждаем вопросы и проблемы организации (выбор структуры), создания, эксплуатации, модернизации (перенос/расширение) и восстановления (ребилда), а также сопутствующие этим вопросам моменты.
Обсуждение выбора RAID-контроллеров ведётся здесь.
Подобрать накопители для массива поможет эта ветка.
Обоснованный выбор оптимального размера страйпа для производительных RAID 0 посредством тестирования в HAB.
Померяться производительностью стоит тут.

В случае описания вопроса выбора, скорости и связанных с этим проблем, просьба ссылаться на посты в соответствующих ветках.

Основы теории массивов: http://wikipedia.org/wiki/RAID
Общая информация по массивам доступна в виде мини-бета-FAQ.
Познавательная статья по контроллерам от програмного массива к аппаратному - Игры с RAID
Полезная статья по восстановлению RAID.
Полезные сведения по работе с RAID-контроллером 3ware 9550SX-8LP, в качестве примера.

Задавая вопрос, постарайтесь как можно полнее описать конфигурацию массива и компьютера в профиле, то что, проделали и текущий результат. Не забываем пользоваться поиском в данной теме и по всему Internet'у!

Intel® Rapid Storage Technology не поддерживает 3TB диски в RAID-режиме, а Rapid Storage Technology enterprise(X79, C600) - работает с ними.

ХЕХ! А у меня HAB вот чего показал на рэйде 0 750 GB!!!


HDD access block, v0.0a

Bench drive: Intel Raid 0 Volume 750GB
Burst read, maximum:
4Kb, speed = 41Mb/sec
8Kb, speed = 70Mb/sec
16Kb, speed = 109Mb/sec
32Kb, speed = 144Mb/sec
64Kb, speed = 165Mb/sec
128Kb, speed = 191Mb/sec
256Kb, speed = 367Mb/sec
512Kb, speed = 388Mb/sec
1Mb, speed = 508Mb/sec
2Mb, speed = 521Mb/sec
4Mb, speed = 255Mb/sec
8Mb, speed = 192Mb/sec
Burst read, average:
4Kb, speed = 30Mb/sec
8Kb, speed = 67Mb/sec
16Kb, speed = 100Mb/sec
32Kb, speed = 134Mb/sec
64Kb, speed = 157Mb/sec
128Kb, speed = 171Mb/sec
256Kb, speed = 331Mb/sec
512Kb, speed = 354Mb/sec
1Mb, speed = 483Mb/sec
2Mb, speed = 519Mb/sec
4Mb, speed = 157Mb/sec
8Mb, speed = 192Mb/sec
Linear reading, average:
4Kb, speed = 35Mb/sec
8Kb, speed = 60Mb/sec
16Kb, speed = 83Mb/sec
32Kb, speed = 112Mb/sec
64Kb, speed = 122Mb/sec
128Kb, speed = 112Mb/sec
256Kb, speed = 170Mb/sec
512Kb, speed = 234Mb/sec
1Mb, speed = 213Mb/sec
2Mb, speed = 227Mb/sec
4Mb, speed = 223Mb/sec
8Mb, speed = 225Mb/sec
__________________________________________

И чего, мне теперь считать 512 или 1 Мб нормальным размером блока?!?!??!?!?!?!?!?!??!?!?!?!?!?!?!

Mitjay P5LD2
Это я о том, что если контроллер не отдает инфу по СМАРТу, то никакая "любая" прога ее не прочтет.

partition magic 8.05 прекрасно видит рейды, созданные интегрированными контроллерами intel и nvidia.

это понятно

но для начала было бы не плохо понять что за "мониторинг" подразумевался

здорово, вот только пропускная способность современных pci-e контроллеров ~300Мб/с .. поправите меня если я ошибаюсь
Добавлено спустя 35 секунд
именно про 8й партишен я и говорил

Да я вот всем этот вопрос тоже хочу задать? У меня в HAB такие резалты, как правильно их воспринять, КОМРАДЫ?!

При этом в Linear reading, average он выше 300-х и не поднимается =))))))))))))

Потестил свой рейд 0 и вот что получилось
#77

Mitjay P5LD2 под мониторингом подразумеваю ... да..да ... контроль смарта, ск-ть чтения и записи + интеллектуальное определение "жизни" хдд (необязательно .. но не помешало бы)

OverRock
Скорость чтения/записи во время работы можно логировать перфмоном.
Я угадал.

-TRANTOR- ... ??? .. что за перфмон?) Perfect Monitor?) ... А смарт контрориловать на каждом диске возможно?

По толкованию данных программы.
Есть два параметра - Burst Read и Linear Read. Первое означает 'идеальные' условия чтения, когда данные лежат уже прочитанные в внутреннем кеши привода. Linear Read - обычное последовательное чтение.
Т.е., быстрее Burst получить данные с привода нельзя. (При больших блоках происходит насыщение очередей ... собственно, такой режим и невозможен в природе, потому на срыв 'Burst' при больших блоках не стоит обращать внимание)
Какие факторы влияют на Burst?
1. как 'далеко' находится накопитель, т.е. время от запроса до получения блока.
2. firmware и его попытки предсказать последующие запросы
3. кеширование в драйвере
4. размер блока передачи информации
5. пропусканая способность интерфейса

По пунктам:
п1. При передаче информации от накопителя в OS используется блочный режим передачи. Одна из его неприятных моментов - блок считается принятым только по получения всех данных блока. Т.о., надо учитывать время от_запроса до момента окончания приема.
Из элементарной логики следует, что пропускной способности SATA1 'за глаза' хватает для такой скорости передачи ... но вот время на передачу блока в SATA1 будет явно больше, чем в SATA2. Тоже касается и интерфейсов между контроллером диска и памятью (данные с накопителя всегда считsdf.ncz в системную память).
Сам контроллер может быть подключен к шине PCIe или PCI. У них разное время доступа. Кроме того, есть 'родные' и 'неродные' контроллеры. Например, в nForce IDE встроен в chipset и потому имеет очень маленькое время доступа.
Как-то делал PCI устройство и был крайне огорчен замером времени доступа к PCI. Если это первичная шина и контроллер находится в чипсете, то его время доступа мало. Для внешних PCI устройств время возрастает очень сильно, буквально 'в разы'. Собственно, мост PCI-PCI и этим все сказано.
У Intel с его 'хабовой' структурой накладывется еще время доступа к 'хабу'.
Потому, потенциально, структура HT от AMD с встроенным IDE должна иметь наилучшие из возможных вариантов подключения IDE диска. Вторым по эффективности (из-за hub организации) идут варианты реализации Intel, потом внешние контроллеры, реализованные прямо на mainboard, потом 'все остальное'. Очень хороший пример привел -TRANTOR- (link)
Очень мощный процессор, очень хорошие диски, а скорость падает практически линейно от размера блока - сказывается большое время доступа к контроллеру, да и сам контроллер явно не слишком быстрый.
Если взять два (почти)одинаковых диска и посмотреть их характеристики в вариантах AMD (nForce4) {слева} и Intel (i965/JMicron), то разница весьма заметна. У AMD диск "ближе", на JMicron 'дальше', что сказалось на Burst при уменьшении блока ... ну и на linear read, естественно.

#77 #77

п2. firmware и его попытки предсказать последующие запросы
Собственно, тут мало что можно сказать. Разные диски, разные версии firmware. У меня на работе достаточно древний диск:
#77
Здесь виновато или чрезмерные аппетиты контроллера по предсказанию чтения (отсюда большое latency) или банально тормозной контроллер.
(да и Burst косвенно на это указывает)


п3. кеширование в драйвере
Есть кеширование записи и кеширование чтения. Если по записи понятно и особо деструктивным действием сие не отличается (ну, запишет 'когда сможет'), то кеширование чтения может вызвать (точнее вызывает) падение скорости. Что такое кеширование чтения? - банальное чтение данных дальше, чем требуется -- а вдруг они потребуются позже? Из-за этого растет время доступа к следующим данным, т.к. пока не передадутся ненужные данные, контроллер не сможет выдать нужные. Немного упростил.
(Потестироваль кеширование чтения в nForce и отключил навсегда. По умолчанию это кеширвоание включено.)
NCQ/TCQ ... на том, что у меня было, это не давало реального ускорения, а вот проблемы и провалы скорости были. Для _Вашего_ случая надо тестировать индивидуально. Я - отключил, это загружает процессор и когда он занят, может вызвать дополнительное падение скорости и рывки/падение FPS.

п4. размер блока передачи информации
Боюсь, влиять на прохождение информации внутри аппаратуры мы не сможем, потому и говорить особо не о чем.
Тут вот в чем дело - контроллер передает информацию блоками, на которым его запрограммировали. Тут есть ограничения на формат посылки, нельзя надолго занимать шину (изначально формат проектировался на PCI). Аппаратно-специфед, потому возможны всякие чудеса.

5. пропусканая способность интерфейса
Ну, пропускной способности даже SATA1 вроде-бы хватит, а вот с другими интерфейсами? PCI уже хватит только на 1 диск и только при том, что больше никто эту шину PCI не использует (в системе может быть несколько шин PCI, между ними ставят мосты)


RAID0 как таковой....
При чтении (да и записи) информации работа с одним файлом разбивается на чтение нескольких файлов меньшего размера, расположенных на нескольки дисках. Для примера, возьмем RAID0 на 2х дисках. При этом чтение (повторяю, и запись) файла разбивается на чтение файла половинной длины диском 0 и диском 1. Причем, диск 0 читает четные сектора файла, диск 1 - нечетные.
В результате --- читается файл в двое меньшего размера и в 2 раза быстрее (в идеале). Отходим от идеала на реальную почву, при уменьшения размера блока интерлива можно получить ситуацию, когда весь блок содержится только на одном из дисков. При этом второй не получит запрос на чтение.
С одной стороны, в 2 раза медленнее, с другой - второй диск свободен и если драйвер поддерживает многопоточность, то на него можно выслать запрос на чтение _другого_ файла.
Как-то давно тестировал и у меня вышло, что родные M$ драйверы это не умеют, в отличии от nForce. Правда, это касалось параллельной работы с двумя независимыми дисками.
Как обстоят дела у производителей с их разноплановыми драйверами (AMD/Intel/JMicron) - болото еще то. (Принцип 'Неуловимого Джо')
Так вот, если драйвер поддерживает многопотопоточность, то уменьшение размера блока интерливинг 'до железки' может и не стоит делать. А вот если не поддерживает, то надо гнать до миниума - иначе Вы банально теряете производительность.
Второй момент - любой нормальный драйвер умеет собирать 'мусор' и при чтении большого файла не высылает много мелких запросов на каждый конкретный контроллер/диск. Т.е. чтение очень большого файла при любом размере блока интерливинг будет идти одинаково.
Если драйвер кривой, то скорость чтения будет зависеть .... тогда стоит поискать новую версию софта.

Еще момент - OS, как и прикладные программы, читают данные блоками. Для выяснения этого есть закладка статистики. Можно позапускать различные программы и посмотреть на размер блока, которыми оперируют. На основании этого можно оценить эффективность того или иного размера интерливинг RAID0. Например, основной блок для OS типа XP составляет 64Kb. Для его ускорения хорошо-бы иметь блок интерливинга в 2 раза меньше (если 2 диска).

И еще момент - чем меньше блок передачи по интерфейсу диск-.-.-.-память, тем болше надо процессорного времени на обработку, ведь каждая передача сопровождается хоть небольшой, но работой процессора (надо настроить BUS Mastering &etc). Если процессор свободен (или их несколько), то проблем нет, а вот на single процессоре и сильной загрузке это может вызвать небольшие локальные загрузки процессора (микрорывки и падение FPS в играх). Потому очень-очень маленькими блоками интерливинг я бы не стал.
На nF4 у меня был блок интерливинг 8К.

Как интертрепировать результаты программы?
Если взять последний пример, то из него следует:
- линейная скорость чтения диска 55MB/s
- burst 97MB/s
- блок, на котром burst = linear read = 16Kb, но при этом скорость чтения падает не на обычные 5-10%, а в 1.5 раза (отличное железо, нечего сказать!), т.е. блок интерливинга в 16Kb даст падение скорости на мелких файлах в 1.5 раза по сравнению с одиночным диском. (Поясню - если один диск, то он бы считал 32Kb, а RAID0 из 2х таких дисков прочитли бы по 16Kb)
Т.е. 16Kb для такого диска -
Значит 32К.

(К Куратору - может добавить в FAQ?)

serj

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

#77

вот тест одного из моих одиночных хардов, которые планирую объеденить в рейд. Железо: c2d, p35 (контроллер интеловский ICH9R)

чего-то никак не пойму какой оптимальный блок интерливинга выбрать для RAID0 (учитывая что хардов будет 2, не больше) + не совсем понял график с результатами - у тебя во всех примерах идёт спад Burst speed примерно с 512к, тут же он одинаков в пределах 128-8мб (и собсно максимален).



равенства burst'а linear read'у я в этом примере не увидел, да и в своём тесте тоже - разница есть либо в одну либо в другую сторону. Но если следовать такой логике, то надо выбирать просто близкие друг к другу варианты. Тогда так:

линейная скорость чтения диска: 82MB/s
burst: 190MB/s
блок на котором burst=linear=...4 либо 8Kb, скорость чтения падает >2 раза при 4кб и почти в 2 раза при 8. Т.е. блок в 8кб даст падение почти в 2 раза на мелких файлах по сравнению с одиночным диском. Т.е. 4-8кб для такого диска -
значит? ....

вот реально ситуация когда посчитал вроде всё и сделал по образу и подобию, но при этом нифига не понял - что будет оптимальнее )) будет ли лучше при таких резалтах сделать блок в 64-128кб? или будет только хуже (на мелких файлах)? или выбрать 16-32...

и ещё:



как? а на intel как по дефолту? и если включено - то как отрубать?

Скорость линейного чтения 82Mb/s. Она начинает снижаться при размере блока в 16Kb (потому, что Burst опустилась до 82Mb/s). Т.е. надо ставить блок интерлива RAID0 в 16-32K. IMHO, естественно.
Не открывайте окно статистики, это не нужно.

(По настройке драйверов под Intel ничего не знаю, текст выше относился к драйверам на nForce)

OverRock
C:\WINDOWS\system32\perfmon.exe

Это зависит от контроллера (повоторяю третий раз). У меня Эверест, например, показывает СМАРТ по всем дискам, а на других контроллерах, к примеру, не показывает. Надо смотреть в каждом случае отдельно.

serj
Спасибо за интересную инфу!

Есть небольшие рац-предложения.

1. Может имеет смысл сделать тест latency burst (причем на разных блоках)? Можно будет определить "удаленность" дисковой подсистемы и, соотв., делать какие-то выводы.

2. Насколько я вижу, в тесте используется очередь = 1. А не сделать ли переключатель, чтобы можно было поставить любую? Будет видно, при какой очереди массив может выйти на свой максимум. Или наоборот - посмотреть, при какой глубине очереди он захлебывается.

serj

спасибо )) теперь понял принцип вычисления )

имеется материнка на p35 (гига p35-dq6), и парочка райд0, не подскажете как безопасно на время "отмонтировать" диск из рейда, допустим потестить его, смарт посмотреть (никакой записи на поверхность естественно) и потом обратно его прикрутить в рейд. На nforce4 все было просто, я уже детали не помню, но был пункт меню в утилите (в которую в процессе загрузки можно было зайти) удалить диск из рейда, присоединить (или ребилд)... Никакая инфа не терялась. На Intel же нет пункта ребилд массива/добавить диск, есть пункт удалить диск сделать его non-raid, и создать новый массив, никакого ребилда.

Тут у меня недавно такой случай был, в процессе экспериментов с разгоном слетел один диск (наверное сам виноват, в момент BSOD выключил комп), при загрузке один массив пишет Fail, один из его дисков отвалился, пишет non-raid. Ошибка логическая, так как сам винт 100% рабочий. Добавить обратно винт и сделать ребилд массива нет такого пункта в меню. Ситуация усугубляется тем что массив загрузочный, на нем стоит система, загрузится не мог. После нескольких попыток перезагрузок, делать нечего решил попробовать перевести второй винт массива в non-raid и создать массив из этих дисков поновой с такими же параметрами (стрип, размер). Перезагрузка выявила, что такая пересборка затерла MBR и таблицу разделов...
Ну что, больше простых вариантов нет, нашел старый IDE винт поставил туда винду, и с помощью Active Partition Recovery восстановил все разделы, потом восстановил загрузчик. Убил на это дело весь вечер и хорошо что помнил какие разделы, какого примерно размера у меня были. Вот думаю наверняка можно было проще сделать?

progn, у меня такое было на JMicron (P965), причем несколько раз в течении нескольки дней, потом улеглось. Для этого пришлось специально озаботится охлаждением северного моста и ... и поставить бОльший диск первым. Хоть оба диска полностью одинаковы по всем характеристикам и куплены в одно время, но один из них на каплю меньше. До этого они замечательно работали в RAID0 на nF4. Теперь я дико боюсь трогать диски.
Это был треп, к сути...
Я бы не стал пробовать (см. выше), но - если очень надо, можно попробовать снять оба диска с хвостов RAID, воткнуть на другой хвост SATA и провести тестирование. В BIOS'е же программируешь линии и контроллеры на RAID. Я бы не стал выключать сам RAID контроллер, вдруг он сбросит свои настройки в BIOS?
Лучший вариант - загрузиться с дискеты с низкоуровневым тестером а-ля mhdd.
Я бы так попробовал, но это тЭоретические измышления.


Добавлено спустя 3 минуты, 6 секунд
-TRANTOR-, если хочешь сделать, пошли в Программирование. У меня не так, чтоб было много свободного времени, но если это кому-то интересно, можно поразвлекаться. Проблема не столько в написании, сколько в разумном алгоритме - диск устройство механическое, страшно инерционное и непредсказуемое. Т.е. на вроде-бы простые действия 'надо много думать'.

если для 2х это 32 то получается для 4х это 16? для оптимальной производительности?.. так?.. если учитывать что XP работает с блоками в 64К .. я правильно понял?