SATA-RAID контроллер FastTRAK S150 SX4 от Promise

Введение

Очередным многоканальным (4 и более) SATA-RAID контроллером, о котором мы собираемся рассказать, является FastTRAK S150 SX4 от Promise. Этот контроллер, как можно предположить из названия, является близким родственником контроллеру FastTRAK S150 TX4. Однако, из общего у них – только поддержка четырех Serial ATA/150 устройств, чем, собственно, и обусловлено сходство в названии. На первый взгляд, FastTRAK S150 SX4 отличается только поддержкой RAID5, но, при более подробном рассмотрении, можно увидеть, что различия значительно существеннее.

Итак, как мы уже говорили, контроллер может поддерживать до четырех Serial ATA/150 устройств (массивы с общей емкостью до 1 терабайта). Типы поддерживаемых RAID-массивов стандартны – 0, 1, 10, 5 и JBOD. За счет способности контроллера работать в 32бит/66МГц слоте PCI 2.2 максимально возможная теоретическая пропускная способность контроллера составляет 266МБ/c. Контроллер FastTRAK S150 SX4 позволяет использовать до 256Мб кэш памяти (64Мб-минимум). Кроме того, на контроллере установлена память FRAM (Ferroelectric RAM) - для ведения журнала транзакций и встроенные GPIO порты для управления устройством. FastTRAK S150 SX4 позволяет расширять емкости массива и изменять уровни RAID в режиме "On-Line". Он поддерживает несколько режимов кэширования (write-back/write-through), режим упреждающего чтения в зависимости от приложений и типов данных), а так же использует пакетные команды и объединение прерываний для уменьшения их количества и повышения производительности, элеваторный поиск основных команд, основанный на определении положения данных на диске и выравнивание нагрузки (только для зеркалированных RAID массивов).

Внешний вид контроллера

Контроллер, как мы можем видеть, маленьким не назовешь, однако, даже при этих размерах, все элементы расположены очень компактно. Практически в центре расположен XOR–процессор PDC 20621. Справа от него находится разъем для DIMM 168-pin, установленный так, что память располагается параллельно плате контроллера. Четыре SATA разъема распределены по верхней кромке платы.
Судя по внешнему виду контроллера FatTRAK S150 SX4, совершенно ясно, что он имеет значительно больше общего с контроллером FastTRAK SX4000, чем с контроллером FastTRAK S150 TX4. Фактически, FastTRAK S150 SX4 - это и есть FastTRAK SX4000, который за счёт применения конвертеров Marvell научился работать с SATA-дисками.

Таблица параметров:

Методика тестирования

Тестовая система:

корпус - Intel SC5200
материнская плата – Intel SHG2;
процессор - 2 x Intel Xeon 2.8/400FSB;
память - 2 x 512MB DDR SDRAM PC2100 ECC Registered;
винчестер - IBM DTLA 307015;
видеокарта – onboard ATi Rage XL;
операционная система - Windows 2000 Pro SP4.

Использовались следующие тесты:

WinBench 99 2.0
IOMeter 2003.02.15

В Winbench99 на логическом диске создавался один раздел на весь объём диска. Тесты Winbench проводились по семь раз, выбирался лучший показанный результат.

Для сравнения скорости работы винчестеров при помощи теста IOMeter использовались паттерны Fileserver & Webserver.


Эти паттерны призваны измерить производительность дисковой подсистемы при нагрузке, типичной для file- и web-серверов.

Паттерн Workstation, используемый нами, создан нашим автором Романовым Сергеем aka GReY на основании статистики обращений к диску при работе различных приложений, приведённой в описании SR Testbed3. Статистические данные собраны на файловой системе NTFS5 в режимах работы Office, Hi-End и Boot-up.


Этим паттерном мы будем руководствоваться для оценки привлекательности винчестеров для обычного Windows-пользователя.

Ну и, наконец, была проверена способность винчестеров работать с Sequential-запросами переменного размера на чтение/запись и скорость дисков в паттерне Database, имитирующем работу дисковой подсистемы с SQL-подобными запросами.

В контроллер был прошито firmware 1.1.0.15, использовались драйвера из того же набора (1.1.0.15). Для контроля состояния массива и для синхронизации массивов использовалась программа 3DM Disk Management. Контроллер устанавливался в слот PCI-X/133МГц (хотя контроллер поддерживает только PCI32 66МГц).

Диски WD360GD (Raptor) устанавливались в штатные салазки корпуса SC5200 и крепились четырьмя винтами за нижнюю грань.


Контроллер FastTRAK S150 SX4 имеет возможность посредством утилиты PAM изменять состояние отложенной записи для винчестеров. Поэтому, в отличие от, например, контроллера 3Ware8506-8 Escalade, мы можем вполне определенно утверждать, что при выполнении основной программы тестирования отложенная запись для дисков разрешалась, а режим работы кэширования запросов драйвером (WriteBack и WriteThrough) менялся по необходимости. Все тесты были проведены при объёме кэша контроллера в 256МБ.

Результаты тестов

По традиции, начнем обсуждение с результатов работы контроллера со смешанными потоками запросов:

IOMeter: паттерн Database

Напомню, что в этом паттерне мы проверяем способность контроллеров работать со смешанным потоком запросов на чтение и запись блоков данных объемом 8КБ со случайным адресом. Изменяя соотношение запросов на чтение и запись, мы можем выявить качество сортировки драйвером контроллера запросов на чтение и запись:

Сначала, рассмотрим результаты работы контроллера в режиме WriteThrough в виде таблицы:


Теперь, для большей наглядности, построим графики зависимости скорости передачи данных от удельного веса запросов на запись для очередей разной длины. Для удобства, разобьем массивы на две группы:

При линейной нагрузке, в начале графика (режим RandomRead), почти все массивы показывают очень близкие скорости, а массивы RAID1 и RAID10 оказываются немного быстрее остальных. Однако, с ростом числа запросов на запись, их скорости становятся все ближе скоростям одиночного диска и массивов RAID0 из двух дисков, а в режиме RandomWrite (100% запросов на запись) даже немного отстают от них. По-видимому, в контроллере FastTRAK S150 SX4, при работе с зеркальными массивами, применяется алгоритм, похожий на Twinstor от 3Ware. Эта технология позволяет по истории предыдущих запросов определять диск, который обработает текущий запрос быстрее, что заметно увеличивает скорость работы с запросами на чтение. Максимальный прирост скорости в данном случае (в режиме RandomRead) составляет 15 процентов. Кстати, если вспомнить FastTRAK S150 TX4, то там в этом режиме чередование запросов между дисками зеркальной пары не работало, так что улучшение налицо.

С ростом вероятности появления запроса на запись скорость работы одиночного диска возрастает - работают алгоритмы отложенной записи винчестера. Соответственно количеству дисков в массиве, растет и скорость массивов RAID0, но пропорциональность наблюдается только в режимах с высокой вероятностью появления запросов на запись. Скорости массивов RAID5 монотонно снижаются по мере увеличения доли запросов на запись, так как эти запросы сильно замедляют их работу. Однако, разницы в скоростях массивов RAID5 из трех и четырех дисков практически не наблюдается, что, несколько, странно.

Увеличение нагрузки меняет картину распределения скоростей. Зеркала - массивы RAID1 и RAID10 всегда, кроме режима RandomWrite (100% запросов на запись), быстрее одиночного диска и массива RAID0 из двух дисков соответственно. Максимальная разница в скорости (режиме RandomRead) составляет 75%, что уже близко к показателям Twinstor от 3Ware. Однако, в отличие от линейной нагрузки, их скорости с ростом числа запросов на запись снижаются, так как количества запросов уже достаточно, чтобы оптимизация чтения с зеркал контроллером была более эффективна, чем оптимизация запросов на запись винчестерами. Массивы RAID0 демонстрируют прекрасную масштабируемость по количеству дисков в массиве во всех режимах работы. А вот на массивы RAID5 увеличение нагрузки практически никак не повлияло. Они продолжают демонстрировать необъяснимое равенство скоростей, причем, судя по тому, что их скорость в режиме RandomRead соответствует скорости массива RAID0 из четырех дисков, скорость массива RAID5 из четырех дисков является нормальной, а скорость массива RAID5 из трех дисков аномально высокой.

Нагрузка в 256 запросов, уже не влияет на распределение скоростей. Зеркальные массивы RAID1 и RAID10 в точке RandomRead почти в два раза быстрее одиночного диска и массива RAID0 из двух дисков соответственно. С ростом числа запросов на запись их превосходство уменьшается до точки RandomWrite, в которой оно сходит на нет. Графики скоростей RAID0 массивов и одиночного диска почти "параллельны". Скорости массивов RAID5 плавно снижаются с ростом числа запросов на запись и, по-видимому, соответствуют скорости массива RAID5 из четырех дисков.

Теперь посмотрим на результаты того же теста в режиме WriteBack. Сначала в виде таблицы:


Затем в виде графиков, построив и сгруппировав их так же, как и при тестировании в режиме WriteThrough:

Здесь мы отметим только изменения вида графиков, по сравнению с режимом WriteThrough, сравнения числовых значений скоростей будут приведены ниже.

Первое, что бросается в глаза, это сильная изломанность графиков. Причиной этих изломов является добавление еще одной оптимизации – отложенной записи контроллера.
Второе явное отличие от режима WriteThrough – рост скоростей массивов RAID5 с увеличением числа запросов на запись и, первое появление значительной разницы в скоростях массивов из трех и четырех дисков, пусть и только в трех режимах. Рост их скоростей вполне объясним тем, что запросы на запись, сильно замедляющие работу массивов RAID5, теперь дополнительно оптимизируются кэшем контроллера. Зеркала - массивы RAID1 и RAID10, все так же, всегда, кроме режима RandomWrite (100% запросов на запись), быстрее одиночного диска и массива RAID0 из двух дисков соответственно.

При нагрузке в 16 запросов массивы RAID0 демонстрируют рост скорости с увеличением числа запросов на запись и хорошую масштабируемость по количеству дисков в массиве. Массивы, использующих зеркалирование (RAID1 и RAID10), все так же, всегда, кроме режима RandomWrite (100% запросов на запись), быстрее одиночного диска и массива RAID0 из двух дисков соответственно. Однако, в отличие от режима WriteThrough, их скорости снижаются только до 80-ти процентов запросов на запись, а при дальнейшем увеличении их числа начинают расти. По всей видимости, это - результат оптимизации запросов на запись контроллером. По этой же причине, у массивов RAID5 при 70-ти процентах запросов на запись замедляется снижение скорости, а в режиме с 80 процентами запросов на запись наблюдается даже небольшой рост. Также, хотелось бы отметить, что массивы RAID5 наконец-то показали различные скорости в точке RandomRead, однако, с ростом числа запросов на запись разница в их скоростях снижается, пока в режиме 70-ти процентов запросов на запись их скорости не сравнялись – необъяснимый результат.

При нагрузке в 256 запросов массив RAID0 из трех дисков демонстрирует снижение скорости с ростом числа запросов на запись, а на графиках массивов RAID5 пропал излом при высокой доле запросов на запись. В остальном, графики качественно не отличаются от нагрузки в 16 запросов.

Теперь, как и обещали, сравним численные значения скоростей всех вариантов RAID-массивов на различных схемах кэширования. Для этого построим еще одну большую таблицу, в каждой ячейке которой содержится результат деления скорости контроллера в режиме WB на скорость контроллера в режиме WT. Таким образом, по величине содержащегося в ячейке числа мы сможем судить об эффективности работы WB-кэширования в каждом конкретном режиме. Если число будет меньше единицы (такие числа мы подкрасили красным цветом), то WB-кэширование здесь вредно, а если число будет больше единицы (такие числа мы подкрасили синим цветом), то WB-кэширование привело к увеличению скорости, т.е. оно полезно.

Если же в ячейке мы видим число "1.0", то это означает, что для этого режима что WB, что WT-кэширование одинаково полезны.


Общее впечатление таково, что для всех массивов, кроме RAID5, WB-кэширование - полезно. А теперь - подробнее:

На одиночный диск, массивы RAID0 из двух и четырех дисков, массив RAID1 и массив RAID10 WB-кэширование оказывает, в целом, положительное влияние. Они демонстрируют усиление этого влияния с ростом числа запросов на запись, и уменьшение его с ростом нагрузки. Максимальный прирост скорости составляет 32, 25, 18, 31 и 29% соответственно. Черные цифры встречаются, в основном, в режиме RandomRead, где отсутствуют запросы на запись и кэшированию не на что влиять. В массивах RAID1 и RAID10 мы можем видеть отрицательное влияние WB-кэширования при нагрузке в 256 запросов, однако, потери в скорости составляют всего 1%, а такие нагрузки практически недостижимы при реальной работе. В массиве RAID10 есть еще один режим – 60% запросов на запись при линейной нагрузке, когда WB-кэширование вредно, но так как в остальных режимах WB-кэширование полезно, то можно сказать, на этот массив, как и на вышеупомянутые, WB-кэширование оказывает только положительное влияние.

На массив RAID5 из четырех дисков отложенная запись контроллера влияет положительно при маленьких и средних нагрузках. Максимальный прирост скорости составляет 183%!!!. Однако при больших нагрузках WB-кэширование начинает оказывать отрицательное влияние, хотя потеря в скорости составляет всего 6%.

В массиве RAID5 из трех дисков, граница между зонами, в которых WB-кэширование оказывает положительное и отрицательное влияние проходит практически по линии между режимом RandomRead при линейной нагрузке и режимом RandomWrite при максимальной нагрузке. Максимальный прирост скорости составляет 190%, максимальная потеря в скорости – 12%. С максимальным приростом все понятно – в точке RandomWrite при линейной нагрузке все массивы демонстрируют максимальную эффективность отложенной записи винчестера, но максимум потери скорости приходится на режим RandomRead, в котором нет запросов на запись, и влияние WB-кэширования невозможно. Еще одна непонятность этого массива…

В массиве RAID0 из трех дисков граница между зонами, в которых WB-кэширование оказывает положительное и отрицательное влияние проходит практически по линии между режимом RandomRead при максимальной нагрузке и режимом RandomWrite при линейной нагрузке. При таком расположении границы в режиме RandomRead состояние отложенной записи контроллера не оказывает никакого влияния на скорость. Зато эффективность WB-кэширования падает с увеличением числа запросов на запись.

Из этого всего можно сделать вывод, что WB-кэширование полезно далеко не всегда, однако, при небольших нагрузках оно, как правило, полезно, а при больших – бесполезно или вредно. Поэтому, следует использовать его в работе или нет – зависит от того, какие массивы будут использоваться, и какая нагрузка на контроллер ожидается.

IOMeter: паттерны Sequential Read&Write

Теперь посмотрим, как контроллер справится с последовательным чтением/записью.
На массив при помощи программы IOMeter подаётся поток запросов на чтение/запись с глубиной очереди команд, равной четырём. Раз в минуту в тесте меняется размер блока данных, так что после окончания теста мы получаем зависимость скорости линейного чтения или записи от размера блока данных. Полученные результаты (зависимость скорости прокачки данных контроллером от размера блока данных) сведены в таблицы:

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


Максимальная скорость чтения достигается разными массивами при разных размерах запросов, то есть тогда, когда контроллер разбивает большой запрос на несколько маленьких, которые выполняются несколькими винчестерами. Масштабируемость скорости работы от количества дисков просматривается, только между массивами RAID0 из двух и трех дисков. Массив RAID0 из четырех дисков выпадает из общей картины.


Рассматривая работу со смешанными потоками запросов, мы предположили, что в алгоритмах чтения с зеркальных массивов используется чередование запросов на чтение между дисками зеркальной пары. Но как видим, этот алгоритм в режиме последовательного чтения оказывает отрицательное влияние на скорость чтения массивов RAID1 и RAID10. Скорость чтения с массива RAID1 всегда меньше скорости чтения с одиночного диска, а массив RAID10 всегда отстает от массива RAID0 из двух дисков.

Графики массивы RAID5, как и в случае Database, повторяют друг-друга.

Теперь посмотрим, как меняется картина при включении WB-кэширования, хотя, вообще говоря, она не должна меняться, так как отсутствуют запросы на запись:

И действительно, графики всех массивов, кроме RAID5 из трех дисков (максимальная скорость которого стала даже меньше, чем скорость массива RAID10), не изменились, по сравнению с режимом WriteThrough.

Переходим к последовательной записи:

Построим графики таким же образом, как и в случае последовательного чтения:


Как видим, все массивы достигают максимальной скорости только при очень больших размерах запросов когда контроллер разбивает большой запрос на несколько маленьких, которые выполняются несколькими винчестерами. Но, во-первых, все массивы RAID0 достигают одного максимума, а во-вторых, только при запросах в 64 и 128 KB массив RAID0 из четырех дисков демонстрирует наиболее высокую скорость.


График массива RAID1 полностью повторяет график одиночного диска, а график массива RAID10, в свою очередь, очень похож на график массива RAID0 из двух дисков. Массивы RAID5 демонстрируют наиболее низкую скорость, при всех размерах запросов, кроме двух самых больших, где они достигают скорости массива RAID10.

Теперь посмотрим, как изменятся графики при включении WB-кэширования. В отличие от последовательного чтения, здесь все100% запросов на запись и, поэтому, изменения должны быть существенны:

Графики массива RAID1 и одиночного диска совпадают. И это понятно – в отсутствие запросов на чтение массив RAID1 работает как одиночный диск. Но вот почему совпадают все остальные графики – загадка. Судя по "гладкости" графиков можно предположить, что скорость работы всех массивов ограничена скоростью центрального чипа контроллера (а точнее - скоростью работы центрального чипа с кеш-памятью).

Теперь посмотрим, на работу контроллера в паттернах, имитирующих реальные нагрузки:

IOMeter: Fileserver&Webserver

Сначала, посмотрим на результат работы контроллера при имитации дисковой подсистемы файл-сервера в режимах WriteThrough и WriteBack:

Построим графики зависимости скоростей работы массивов от глубины очереди запросов:

Массивы RAID0 демонстрируют прекрасное масштабирование по количеству дисков в массиве. Массивы RAID1 и RAID10 всегда быстрее одиночного диска и массива RAID 0 из двух дисков и одиночного диска соответственно. Скорости массивы RAID5, как и в предыдущих тестах, равны.

При включении WB-кэширования скорость почти всех массивов увеличилась. Из принципиальных отличий от режима WriteThrough хотелось бы отметить только появившуюся разницу в скоростях массивов RAID5 из трех и четырех дисков.

Для сравнения производительности различных RAID-массивов применим рейтинговую систему. Считая все нагрузки равновероятными, общий балл будем рассчитывать, как среднее значение скорости обработки контроллером запросов при всех вариантах нагрузки:


Массив RAID0 из четырёх дисков удержал первое место по производительности, но только потому, что в паттерне Fileserver 20% операций записи, которые RAID0-массив исполняет быстрее, чем массив RAID10. Массив RAID1, отстал от массива RAID0 из двух дисков, в режиме в режиме WriteThrough, но обогнал его в режиме WriteBack. Массивы RAID5 из двух и трех дисков так же меняются местами при различных состояниях отложенной записи.

Теперь посмотрим на результат работы контроллера при имитации дисковой подсистемы веб-сервера, чьей отличительной чертой является отсутствие запросов на запись. Сначала в виде таблиц:

А теперь в виде графиков:

Отсутствие запросов на запись приводит к тому, что отличий в скоростях массивов при WT- и WB-кэшировании нет совсем. Исключением, как обычно, является массив RAID5 из трех дисков, на который режим WriteBack влияет не лучшим образом. Еще одним следствием нагрузки при 100% запросов на чтение, являются очень высокие скорости зеркальных массивов и массивов RAID5.

Посмотрим на производительность различных массивов, применив рейтинговую систему и рассчитывая общий балл, так же как и в паттерне Fileserver:


Рейтинговая система, более наглядно демонстрирует равенство скоростей всех массивов (кроме RAID5 из трех дисков) при разных состояниях отложенной записи контроллера. Массивы, использующие зеркалирование, а так же массивы RAID5 показали большую производительность, чем массивы RAID0 из соответствующего числа дисков.

IOMeter: Workstation

Паттерн Workstation имитирует интенсивную работу пользователя в различных приложениях на файловой системе NTFS5. Результаты работы контроллера в режимах WriteThrough и WriteBack следующие:

Построим графики зависимости скоростей работы массивов от глубины очереди запросов:

Массивы RAID0 достигают максимальной скорости при небольших очередях запросов, однако, масштабируются по количеству винчестеров только массивы из двух и трех дисков. Максимальная скорость массива RAID0 из четырех дисков ненамного превосходит скорость массива из трех. Скорость массива RAID10 очень близка, а в некоторых режимах даже выше скорости массива RAID0 из четырех дисков. Скорость массива RAID1 всегда выше одиночного диска, даже с учетом падения при количестве запросов в очереди превышающем 2. Скорости массивов RAID5, по традиции контроллера FastTRAK S150 SX4, в режиме WriteThrough равны.

Разрешение отложенной записи контроллера приводит к тому, что увеличивается максимальная скорость массива RAID0 из четырех дисков, однако, в масштабирование по числу дисков в массиве, как это можно наблюдать в массивах RAID0 из двух и трех дисков, он все равно не вписывается. Массив RAID5 из четырех дисков при очередях меньше четырех запросов отстает, а при больших обгоняет массив RAID5 из трех дисков.

Для сравнения между собой производительности разных RAID-массивов в зависимости от использования WB-кэширования составим диаграмму с рейтингами быстродействия массивов. Рейтинг для паттерна Workstation мы считаем по следующей формуле:

Производительность = Total I/O (queue=1)/1 + Total I/O (queue=2)/2 + Total I/O (queue=4)/4 + Total I/O (queue=8)/8 + Total I/O (queue=16)/16 + Total I/O (queue=32)/32


Наличие большой доли запросов на запись, а так же по причине того, что вероятность коротких запросов выше, привело к тому, что массив RAID5 из четырех дисков, занял последнее место. Массив RAID5 из трех дисков, благодаря сравнительно высокой скорости на коротких запросах оказался более производительным, чем одиночный диск. По той же самой причине, массивы RAID1 и RAID10 обогнали массивы RAID0 из соответствующего числа дисков.

Winbench99

Последним в нашем обзоре будет пакет Winbench, который уже несколько лет служит нам в качестве "измерителя" производительности винчестеров при работе с "десктопными" приложениями в файловых системах NTFS и FAT32.

Сначала рассмотрим результаты тестирования в системе NTFS. Таблицы с данными, полученными в режимах WriteThrough и WriteBack, приведены ниже:

Сравним скорости различных массивов по двум интегральным подтестам - Business Disk Winmark и High-End Disk Winmark:

Общая картина для обоих режимов такова - первые три места завоевали RAID0-массивы, два последних места - массивы RAID5, а скорость всех массивов при WB-кэшировании хоть ненамного, но выше, чем в режиме WriteThrough. Однако, в режиме WriteBack массивы RAID5 из трех и RAID0 из двух дисков обогнали массивы RAID5 из четырех дисков и RAID0 из терх дисков соответственно. Отметим так же, что в этом режиме одиночный диск оказался быстрее массива RAID1.

Теперь посмотрим на данные, полученные системе FAT32 при WB- и WT-кэшировании:

Как и в системе NTFS сравним скорости различных массивов по двум интегральным подтестам - Business Disk Winmark и High-End Disk Winmark:

По сравнению с тестированием в системе NTFS все массивы показали более высокую скорость. Распределение массивов по местам осталось прежним – первые места у массивов RAID0, последние – у массивов RAID5. Однако, при изменении состояния отложенной записи порядок массивов остается прежним.

Так как скорости линейного чтения одинаковы для NTFS и для FAT32, то приведем две диаграммы для обеих файловых систем:

Вообще говоря, считается, что скорость линейного чтения не зависит от состояния отложенной записи, так как запросы на запись отсутствуют. Однако, массив RAID5 и здесь сумел продемонстрировать значительное изменение скорости при включении WB-кэширования. Причем, как увеличение скорости в начале дисков, так и уменьшение в конце. Удивительный массив.

Графики линейного чтения для каждого массива приведены отдельно:

График линейного чтения 1HDD - JBOD
График линейного чтения 2HDD - RAID1
График линейного чтения 2HDD - RAID0
График линейного чтения 3HDD - RAID0
График линейного чтения 3HDD - RAID5
График линейного чтения 4HDD - RAID0
График линейного чтения 4HDD - RAID5
График линейного чтения 4HDD - RAID10

Выводы

По результатам тестов о контроллере остается, в целом, благоприятное впечатление. Особенно хорошо он показал себя в тестах, имитирующих работу реальных приложений. Претензии, которые предъявлялись результатам работы массива RAID5 из трех дисков, выражались, в основном, в том, что его скорость при WT-кэшировании оказалась несколько выше ожидаемой (предположение, что мы вместо конфигурации 3HDD RAID5 еще раз протестировали четырёхдисковую имеет право на существование...).

Невысокие результаты работы с последовательными запросами и незначительное влияние такого большого ( 256МБ ) кэша контроллера, будут интересны только специалистам. Для них мы готовим отдельную статью, в которой мы сравним быстродействие контроллера Promise FastTRAK S150 SX4 при использовании в качестве кэш-памяти модулей ёмкостью 64, 128 и 256МБ.

На текущий момент, с сайта производителя можно скачать драйвера для Windows 2003/XP/2000, SuSE Linux, RedHat 8x и 9x Linux. Однако, в отличие от www.promise.ru, которые утверждают, что есть драйвера и для FreeBSD 4.8 Beta, на www.promise.com написано "Free BSD 4.7 (coming soon)". Что означает сия фраза, думаем, и так все знают...