Raid 0 скорость не увеличилась
Давным давно понравилось мне хранить файлы на домашнем сервере - всегда доступны, легко найти, обновить или переименовать и т.п. Много удобнее кучи болванок в сумке.
Потом меня стала заботить сохранность этого добра - все-таки винчестеры ломаются, хоть и не часто при соблюдении режима питания и температуры
Захотелось мне RAID. Про встроенные почитал - жуть, лучше не пользоваться, ибо все-одно юзает процессор, при том что часто рассыпается. Софтварный - тоже не то.
Вообщем зхотелось мне RAID 5. Прикупил старенький PCI адаптер Dell CERC ATA 100/4ch (который OEM LSI MegaRAID 100/4ch), подключил к нему 3 barracuda 7200.9 по 500Gb и разочаровался - скорость записи около 5 Mb/sec. Причем как в венде, так и в linux.
Почитал интернет - у многих так. Единственно советовали включить режим кэша write back. У меня сервер на UPS'е, включил - скорость стала от 10 до 15 Mb/sec. Я обрадовался, но не очень.
Сделал вывод, что дело в железе. Захотел современую RAID карточку для PCI-X чтоб SATA II умела, тем более что ATA винты все сложнее купить, по крайней мере в нашей глубинке.
Купил Intel SRCS28X (который OEM LSI MegaRAID MR300-8XPB). Подключил к нему 3 barracuda 7200.11 по 1Tb и разачаровался так, что аж слеза навернулась - такое бабло, и в итоге скорость записи 5 Mb/sec! В настройках рейда write back не включается без бакап батарейки, цена которой 7 т.р. Вообщем купил вместо нее еще одну барракуду и собрал RAID 10 - который для меня был всегда эталоном скорости, надежности и недоступности. Ибо дорого.
И тут я разочаровался в очередной раз. Скорость записи на RAID 10 - 40 Mb/sec максимум. Этож скорость записи на один отдельно взятый винчестер? Где же распараллеливание?
Этот RAID я в windows не тестировал - ибо лень мне ставить винду, да и не буду ей пользоваться, даже если там быстрей будет.
Так вот вопрос в чем - где я не прав? Почему такие скорости?
Или так и надо? А какже тесты в инете? Или LSI - говно, и нужно раскашеливаться на 3ware? Или это Seagate виноваты? Или драйвера в ядре?
Предисловие.
Собрав осенью 2008 новый "системник", я добился удовлетворившего меня уровня производительности и сбалансированности компонентов, но вот незадача, из всего этого явно выбивался мой "жесткий" 500GB Seagate 7200.11(тогда про проблемы с прошивкой было мало чего известно и меня это естественно не беспокоило). У меня постоянно создавалось ощущение, что система то и дело упирается в его скорость. Появилось желание его "разогнать" тем или иным способом, разумеется затратив наименьшее количество дензнаков. Собственно поэтому я и решил заняться этим "исследованием".
Сейчас в моде всеразличные "технологии удвоения" и даже "учетверения": многоядерные процессоры, связки из нескольких видеокарт, многок.
Тестовый стенд и методика тестирования
Вообще, тестов HDD в сети море, но все они содержат в себе в основном синтетику того или иного рода. А реальные приложения пролетают мимо по причине того, что как измерить производительность там, неясно. Я с этим тоже столкнулся. Я решил, что из обычных задач наиболее зависят от HDD операции установки программ и их загрузки. Вот время осуществления этих операций я и замерил. Почему я не включил операции копирования? Ну как по мне, было бы довольно странно в домашних условиях(что абсолютно не исключает того, что в каких-то профессиональных задачах это может понадобиться), что-то копировать или перемещать с диска на диск, а копирование с/на внешних носителей всегда ограничено скоростью этих внешних носителей. Такое дело как "бэкап" я не затронул просто потому, что с ним никак не вяжется RAID0 на встроенном контроллере. Без синтетики не обошлось разумеется, т.к. надо было проверить, для начала, что всё функционирует как надо.
Моя система:
Процессор: Intel Core 2 Quad Q6600 @ 3,7GHz
Материнская плата: ASUS P5Q Pro FSB@412MHz BIOS 1613
Оперативная память: 2*2GB DDR2-825 Kingston 5-5-5-15 PL11 2T
Видеосистема: Gainward Radeon HD 4850 и CrossFire HD 4850 Частоты: 625/1990MHz
Контроллеры SATA HDD:
Intel ICH10R
Marvell 88SE6111+ SiliconImage 5723*
Silicon Image 3132. BIOS: 7.4.05
*данное решение сделанное инженерами ASUS на этой плате называется DriveXpert(далее я буду называть его Marvell т.к. именно он является дополнительным PCI-E x1 SATA контроллером и чтобы не перепутать его с отдельным SiliconImage) и представляет собой вот такую хитрую систему:
Жесткий диск:
Пара Seagate Barracuda 7200.10 320GB 3.AAE SATA AHCI
Seagate Barracuda 7200.11 500GB SD1A SATA AHCI
Я протестировал одиночные диски, создал массивы 0 уровня из 2х дисков на 320GB на 3х разных контроллерах, а также добавил свой 500Гб диск и посмотрел что из этого выйдет. Также я проверил влияние размера stripe на скорость массива.
Для измерения скорости дисковой подсистемы я использовал следующие тесты:
Время установки ОС Windows Vista, точнее время копирования файлов на диск на начальном этапе установки.
Время загрузки этой же системы: в банальном количестве пробежавших за это время полосок, и полное время от выбора ОС до загрузки рабочего стола в секундах.
Время установки игры GTA4. Источником служил мой терабайтный WD Black.
Время установки игры Crysis.
Время загрузки 1го уровня игры Crysis.
Время установки игры FarCry 2.
Уровень производительности при первом прогоне бенчмарка игры Crysis. (проверялось 3 раза, каждый следующий после перезагрузки, чтобы исключить влияние ОЗУ).
Уровень производительности при первом прогоне бенчмарка игры FarCry 2. (проверялось 3 раза, каждый следующий после перезагрузки, чтобы исключить влияние ОЗУ)
Результаты тестов:
• Установка Windows Vista
Скорость судя по всему ограничивающим фактором послужил DVD+RW привод с которого и шла установка.
*на 500Гб диск система устанавливалась только один раз при подключении к контроллеру ICH10, и другие тесты проводились после банального переподключения этого диска с "южника" на Marvell.
• Загрузка Windows Vista
В лидерах массив из двух 320Gb дисков на ICH10R с размером "страйпа" - 128Кб. Улучшение по сравнению с одним диском почти 2х кратное. За ним замедлившийся, после добавления отличающегося 500Гб диска, массив из 3х дисков. И почти на уровне с ним одиночный 500Гб, учитывая, что при чтении кэш играет значительно меньшую роль нежели при записи, можно отнести значительное повышение скорости загрузки на увеличение плотности записи в 1.5 раза. Дополнительные контроллеры снижают скорость загрузки. Особенно плохо получилось с Marvell'ом (кто бы мог подумать ) - во время загрузки система начинала вдруг опрашивать DVD+RW привод и на это уходило порядочное количество времени и само время загрузки и так была значительно хуже чем в других случаях.
• Тестирование с помощью HDTune
Прирост минимальной скорости близок к двукратному, но только когда RAID организован силами "южника", при этом он уверенно обходит одиночный 500Гб. Заметно вперед вырвался массив из 3х дисков. Теория не врет .
Дополнительные контроллеры судя по всему ограничивают максимальную скорость и при использовании более быстрых дисков от них будет больше вреда чем пользы.
как и ожидалось разница минимальна т.к. серьёзно зависит только от скорости вращения шпинделя, а она везде одна - 7200о/м
• Установка GTA4
RAID0 из 2х дисков не впечатлил, зато впечатлил 500Gb - сыграли свою роль и плотность записи и кэш. Видимо он же и вытянул массив из 3х дисков. Среди контроллеров предпочтительнее оказался SiliconImage, но разница невелика.
• Установка Crysis
Хм. либо всё уперлось в источник(WD Black1TB) либо в разархивирование которое зависит от процессора. В любом случае разница минимальна.
• Установка FarCry2
Здесь оказалась важна линейная скорость и на высоте оказались RAID0 массивы, а одиночный 500Гб подотстал. В любом случае установка заняла около 2х минут и значительную часть(до половины всего времени) её составляли операции по установке дополнительных компонентов типа directX, visual c++ redistr.и прочих.
• Загрузка Crysis
Наиболее важный для меня тест оказался очень привередлив к контроллеру и его задержкам, так что "южник" собственной персоной "на коне". Впрочем разница не очень велика.
Также я хотел попробовать оценить влияние на собственно скорость игры, мы ведь когда играем "3х кратных прогонов с целью минимизации влияния жесткого диска" не делаем. Однако ничего толком не вышло
• Crysis (Direct3D 10) – версия игры 1.2.1, профиль настроек “VeryHigh”, тест видеокарты gpu_bench с помощью утилиты Crysis BenchmarkTool v1.0.0.5
Какой-то логичной зависимости нет - все в пределах погрешности. Странно повел себя 500Гб подключенный к Marvell'у, с ним бенч выдавал строго на пару кадров больше, причём и в последующих прогонах когда от него ничего не должно было зависеть.
• FarCry 2(Direct3D 10) – версия игры 1.0.2.0. Настройки качества Ultra High. Демо Ranch Small.
Здесь уже что-то проглядывается. Игра всё время "шуршит" дисками и ускорение дисковой подсистемы позволило увеличить минимальный FPS. Но важна латентность, скорость доступа и хвалёный ASUS'ом DriveXpert(он же Marvell) с треском проваливается.
Теперь пришло время обобщить все вышеприведенные результаты. С установкой всё предельно ясно: я устанавливал игры с отдельного WD Black 1Tb, а ОС с обычного DVD+RW привода. Если бы устанавливалось с USB flash например то наверняка разницы не было бы вообще - упор в скорость носителя с которого происходит чтение.
А вот с загрузкой интереснее: явно свою роль играет плотность записи т.к. "новый" Seagate явно быстрее "старого", также для записи критичен объём кэша и разумеется качество firmware(которое к слову у Seagate в последнее время сильно хромает). Поэтому и RAID0 из 2х одинаковых HDD ускорил загрузку. Но только когда он подключен к "нормальному" ICH10R, Marvell-DriveXpert пострадал из-за своей мудрёности, а Silicon Image видимо ничем не лучше чем встроенный контроллер, но из-за задержек шины PCI-E x1 его результаты хуже.. а может просто драйвера.
Заключение
Несмотря на некоторую противоречивость, "разгон" дисковой подсистемы прошел успешно и мне удалось зафиксировать ускорение множества обыденных задач таких как загрузка программ и игр, а также их установка (при которой происходит и копирование и разархивирование). Приятно удивило ускорение этих же задач при переходе на HDD с более "плотными" пластинами и увеличенным кэшем(именно в этом направлении сейчас бытовые HDD и развиваются).
Должен впрочем сказать, что по ощущениям разницы между самым быстрым из получившихся массивов и одиночным 320Гб диском не было. Виной тому одинаковое время случайного доступа.
Однозначно рекомендовать построение RAID0 на обычных дисках я не могу, т.к. стоимость такого решения всё-равно будет чуть-ли не втрое превышать стоимость одного диска(два для массива и один для хранения ценных данных). К тому, же быстрый диск нужен для ОС и программ/игр, но они вряд-ли у кого-то занимают объём более 500-600Гб.. обычно куда как меньше. А как мы видели RAID0 на дисках с меньшей плотностью записи совсем немного выигрывает у одиночного но более "плотного" диска. Который к тому-же не потребует покупки дополнительного диска для ценных данных.
Недавно вышли диски с плотностью записи 500Гб на пластину - т.е. втрое и вдвое выше чем у протестированных мною дисков, с большой долей вероятности можно сказать что такие диски превзойдут любую из протестированных конфигураций. А стоят они смехотворно мало по сравнению с 10к дисками и даже RAID'ом из менее емких 320Гб(однопластинных) дисков. Ну а 1ТБ под программы это на мой взгляд немного странно..
Впрочем во время написания этой статьи я наткнулся вот на такой материал где описывается методика уменьшения времени доступа на обычных 7200 дисках.
http://www.thg.ru/storage/short_stroking/index.html
Ну и конечно нельзя не упомянуть о пресловутых SSD дисках, дешевеющих не по дням, а по часам, у которых латентность практически нулевая, скорость чтения достигает 250МБ/с (OCZ Vertex 120Гб и более), правда с записью есть некоторые проблемы, так же как и с ресурсом (MLC), но думаю скоро всё это будет преодолено, а цены за ГБ упадут хотя-бы до уровня WD VelociRaptor.
На такой приятной ноте я и закончу свое "повествование".
п.с. забыл про stripe size.
судя по всему правильно сказано - от добра, добра не ищут и надо использовать тот размер который сам производитель контроллера счел наилучшим (хотя поэксперементировать никто не запрещает)
Все знают, что SSD это здорово. Многие также считают, что RAID массивы – залог высокого быстродействия. А хотели ли вы собрать RAID из SSD? Или может быть прикидывали, что выгоднее: приобрести один большой диск, либо наладить совместную работу нескольких маленьких?
Конфигурирование RAID
Энтузиасты наверняка знают, как выполнять эти действия, но для тех, кто только собирается знакомиться с массивами, подобный материал может быть полезным. Да простят меня сторонники AMD, объяснять я буду на примере указанного выше стенда «Wintelidia».
Прежде всего, необходимо переключить в BIOS режим работы чипсетного контроллера в режим RAID.
реклама
Если переключение производится после установки операционной системы, это чревато потерей ее работоспособности и бесконечным падением в синий экран. Для решения такой проблемы следует воспользоваться инструкцией Microsoft.
Предположим, с этим все хорошо. Если ОС еще не установлена, можно войти в меню самого контроллера и создать массив в его утилите. Для этого нужно успеть нажать CTRL+I во время загрузки.
Если же есть возможность загрузиться с отдельного диска, проще всего поставить фирменные драйверы Intel и воспользоваться консолью Rapid Storage Technology. При наличии подходящих дисков будет доступна кнопка «Создать».
На первом шаге необходимо выбрать тип массива.
Затем выполнить непосредственно настройку. Есть возможность не создавать RAID с нуля, а взять за основу одиночный диск с данными. Кроме того, для всех массивов (кроме «зеркала») можно выбрать размер полосы данных, он же размер страйпа (stripe size). Это определяет размер блоков, на которые разбиваются данные. Большие значения полезны для работы с большими файлами, маленькие – прежде всего для маленьких транзакций в стиле СУБД (хотя все сильно зависит от СУБД, типа массива, вида нагрузки, настроения разработчиков прошивки контроллера и прочих особенностей). Обычно лучше оставлять настройку по умолчанию.
В RAID-0 Intel рекомендует использовать 16 кбайт для SSD и 128 кбайт для HDD – так написано в справке. На практике же для SSD выставляется значение 32 Кбайта, так что для большинства сценариев буду использовать именно его.
реклама
Также можно включить кэш обратной записи тома, который по умолчанию выключен. В этом случае записываемые на массив данные не сразу отправляются на диски, а временно сохраняются в кэше (для чипсетного контроллера это оперативная память компьютера).
Таким образом, повышается скорость операций записи, но одновременно увеличивается риск потери данных в случае сбоев. Мы все делаем «бэкапы» (правда ведь. ) и ждем от RAID-0 максимальной производительности, так что во всех тестах этих массивов кэш будет включен.
Можно управлять еще и кэшем самих дисков в массиве. Он включен по умолчанию. Для RAID-1 будет проведено измерение производительности без кэшей, поскольку если речь идет о надежности, то уже не до высоких скоростей.
Кстати, сценарий не такой уж экзотический. Windows Server, будучи контроллером домена, всегда отключает кэш системного диска. Если нет дискретного RAID контроллера, который слушается только своего драйвера, скорость жестких дисков упадет в несколько раз. Посмотрим, как ведут себя SSD.
В моем случае отключение кэша через Intel RST почему-то не работало – после перезагрузки он включался вновь. Пришлось воспользоваться «Диспетчером устройств», а именно снять галку «Разрешить кэширование записей для этого устройства» в свойствах RAID массива.
Эта настройка и Intel RST взаимосвязаны, после снятия галки параметр «Кэш данных диска» также переходит в состояние «Выключен» и остается таким после перезагрузок.
В итоге будут протестированы следующие конфигурации:
- Vertex 3 RAID-0, размер страйпа 32 Кбайта;
- Vertex 3 RAID-0, размер страйпа 128 Кбайт;
- Vertex 3 RAID-0, подключение через порты SATA-II;
- Vertex 3 RAID-0, медленный ЦП (активны два ядра, HT отключен, частота 2400 МГц, память 1066 МГц CL7);
- Vertex 3 RAID-1, кэш массива и дисков включен;
- Vertex 3 RAID-1, кэш массива и дисков выключен;
- Crucial M4 RAID-0, размер страйпа 32 Кбайта;
- Crucial M4 RAID-1, кэш массива и дисков включен;
- Crucial M4 RAID-1, кэш массива и дисков выключен;
- Одиночный Vertex 3;
- Одиночный Crucial M4;
- Жесткий диск WD5000AAKX.
Тестирование в классических бенчмарках
Crystal Disk Mark
Скорость линейного чтения, Мбайт/с
Включите JavaScript, чтобы видеть графики
Почти двукратный прирост скорости в RAID-0 вполне ожидаем. Размер страйпа не оказывает практически никакого влияния на больших файлах, процессорозависимость бенчмарка отсутствует. А вот SATA-II подключение резко ограничивает возможности системы до уровня одиночного устройства, подключенного через SATA-III.
Удивительно быстро работает RAID-1, не иначе как чтение осуществляется с двух накопителей одновременно. Раньше в тестах жестких дисков такого не наблюдалось, но то была более старая платформа и старые драйверы. При случае надо будет проверить парочку HDD.
Скорость линейной записи, Мбайт/с
Включите JavaScript, чтобы видеть графики
На записи все меняется. Маленькие M4 слабы на запись, поэтому даже одиночный Vertex 3 обходит RAID-0 из двух дисков Crucial. Можно заметить, что отключенный кэш несущественно снижает скорость «зеркал».
Скорость случайного чтения (блок 512 Кбайт), Мбайт/с
Включите JavaScript, чтобы видеть графики
реклама
Удивительно, но на чтении крупными блоками «страйпы» существенно замедляются и лидерами оказываются массивы RAID-1, причем без кэшей. На ошибку не похоже – и Vertex 3, и M4 ведут себя одинаково.
Скорость случайной записи (блок 512 Кбайт), Мбайт/с
Включите JavaScript, чтобы видеть графики
В данном случае картина осталась похожей на ту, что была на линейной записи. Разве что механический диск замедлился почти вдвое.
Скорость случайного чтения (блок 4 Кбайт), Мбайт/с
Включите JavaScript, чтобы видеть графики
Обычно так оно и происходит: во время проверки чистого времени доступа на чтение массивы только мешают.
Скорость случайной записи (блок 4 Кбайт), Мбайт/с
Включите JavaScript, чтобы видеть графики
Кстати, обратите внимание, насколько сильно проявилась процессорозависимость. Загрузка ЦП в этом тесте действительно высока.
Скорость случайного чтения (блок 4 Кбайт, длина очереди 32), Мбайт/с
Включите JavaScript, чтобы видеть графики
На глубокой очереди «марвеловские герои» просто потрясающи – сто тысяч IOPS за смешные деньги.
Скорость случайной записи (блок 4 Кбайт, длина очереди 32), Мбайт/с
Включите JavaScript, чтобы видеть графики
Множество параллельных операций записи позволяют одиночному Vertex’у, зеркалам без кэша и системе с медленным CPU восстановить свою производительность. Все участники (кроме жесткого диска) работают как в сценарии с крупными блоками.
PCMark 7
Windows Defender, Мбайт/с
Включите JavaScript, чтобы видеть графики
importing pictures, Мбайт/с
Включите JavaScript, чтобы видеть графики
Video editing, Мбайт/с
Включите JavaScript, чтобы видеть графики
Windows Media Center, Мбайт/с
Включите JavaScript, чтобы видеть графики
adding music, Мбайт/с
Включите JavaScript, чтобы видеть графики
starting applications, Мбайт/с
Включите JavaScript, чтобы видеть графики
gaming, Мбайт/с
Включите JavaScript, чтобы видеть графики
storage score, баллы
Включите JavaScript, чтобы видеть графики
Разнообразие есть только в тесте importing pictures, в нем доминируют Vertex’ы.
Подпишитесь на наш канал в Яндекс.Дзен или telegram-канал @overclockers_news - это удобные способы следить за новыми материалами на сайте. С картинками, расширенными описаниями и без рекламы.
Что за raid, диски, интерфейс, контроллер, размеры буферов I/O?
С такими детальными ответами диалог будет длиться два дня. Какой именно?
Файловая система ext4 4 идентичных диска:
Stride и Stripe width как считал?
Я ничего не считал, просто сделал по умолчанию
Тады посчитай тулзой по ссылке, а потом примени с помощью tune2fs.
Впрочем, по равенству скоростей чтения и записи можно предположить ограничение по пропускной способности шины.
выключил торрент и повторил:
А скока надо? Отдельно каждый винт как выдает?
Вообще, завидую. С межделмаш-хранилища по SAS обычно меньше 150 имел.
А что за параметр «number of filesystem blocks (in KiB)» и где его посмотреть ?
И почему скорость записи БОЛЬШЕ скорости чтения . Как это вообще может быть ?
Надо делать sync и сбрасывать буферы
тогда не будет странно.
А что за параметр «number of filesystem blocks (in KiB)» и где его посмотреть ?
Размер блока ФС, как я понимаю.
Что не так делаю ?
По умолчанию, Stride и Stripe width получились такие, как рекомендует тулзовина.
Что удивительного? Запись закэшировалась в буфер. Можно посмотреть что будет с опцией oflag=direct. Нужно ещё bs больше сделать
Почему такая большая разница .
Уточни пожалуйса, какая именно разница интересует :)
Почему падает скорость с 5.7 GB/c до 205 MB/c ?
> Почему падает скорость с 5.7 GB/c до 205 MB/c ?
Файловый кэш. Ваш К.О.
В первом случае все 4гб влезают в кеш и чтение идёт из памяти. Во втором 6гб не помещаются целиком и приходится всё читать с диска.
>Вообще, завидую. С межделмаш-хранилища по SAS обычно меньше 150 имел.
Меньше 150 если все диски в RAID-0 объеденить?
В первом случае все 4гб влезают в кеш и чтение идёт из памяти. Во втором 6гб не помещаются целиком и приходится всё читать с диска.
Пусть так, но почему скорость чтение МЕНЬШЕ скорости записи . Вообще скорость обычного диска примерно 30мб/с(запись) 90мб/с(чтение), raid-0 должен только «умножить» на количество дисков скорость записи и чтения. Нет .
Потому что при записи файл физически еще не записался на диск.
Вроде да, да и цифры, как видишь, поменялись.
Вообще скорость обычного диска примерно 30мб/с(запись) 90мб/с(чтение)
Где вы такие диски берёте. Давно уже линейные скорости чтения и записи примерно одинаковые, от 70-100 мб/сек для обычных дисков.
Пусть так, но почему скорость чтение МЕНЬШЕ скорости записи .
Это не номинальная скорость носителя, а фактическая с учётом отложенной записи через кэш. Для устранения эффектов кэша нужно использовать oflag=direct и писать прямо на блочное устройство, а не в файл.
вопрос тот же. почему скорость чтения и запись «одного порядка» ??
мне кажется, что скорость чтения должна быть больше скорости записи, хотя бы в 2 раза . нет ?
Тезис «надежность падает в 2+ раза» опускаем, как очевидный.
Предвещая вопроса «нахрена»:
В первую очередь - объединение пространств двух (одинаковых) ссд в единый том.
Во вторую - не буду врать, есть надежды на некоторый прирост i\o и линейных скоростей. Но это не сверх критично.
На какие грабли можно наступить?
Читал статьи, что 0й рейд на большом числе ссд кончается почти фейлом, ибо массив всегда ждет самый тормозной. Но на парочке могут быть какие проблемы?
Посмотри, есть ли запас пропускной способности у SATA контроллера, а то линейная может и не увеличится.
Ну и TRIM, скорее всего работать не будет.
В остальном проблем не должно вроде быть, пока один из дисков не сдохнет.
Ну и TRIM, скорее всего работать не будет.
А вот давай подробнее :)
Почему по мере заполнения SSD падает скорость записи в RAID, или зачем нужен TRIM
сказал бы, на чём raid0 делать собираешься.
Пробежался по статье, странно, что ранее ее не видел. Пасиба.
Собирать буду на RST (X99). Причем на него же и систему вкорячивать.
Но теперь надо придумать методику тестирования под мои задачи. Вообще массив почти всегда будет пуст процентов на 80-90%. И использоваться только под кэши молотилки жипегов. (много кэешей)
Есть предположение, что mdadm уделает этот RST по всем параметрам, и TRIM в raid0 он умеет.
а не проще интеловский рейд тогда?тот вроде умеет трим
у тебя вполне 0 рейд умеет сама плата и проц, если он интел, все платы например z97 умеют рейд.
erzent ☆☆ ( 01.03.15 17:28:15 )
Последнее исправление: erzent 01.03.15 17:28:47 (всего исправлений: 1)
массив почти всегда будет пуст процентов на 80-90%
если он хоть раз заполнится на 80-90%, то без TRIM, скорость записи снизится «навсегда», хоть он потом даже и пустой будет
многие ссд вообще наполнять свыше 60% нельзя, потом скорость падает ужас.
Читайте также: