Есть желание взять
FastTrak TX2650
http://www.promise.ru/production/sas_sa ... /fttx2650/
(2200р)
и
1-2шт
http://price.sunrise.ru/descriptionPage ... &s=&p=4390
(4400р)
или сразу
http://price.sunrise.ru/descriptionPage ... &s=&p=6790
(6800р)

Думаю 2х74 SAS+controller куда интереснее и лучше чем один Раптор 150GB SATAI за 5200р.
Интересна какая будет скорость массива, только боюсь не упрется ли в ограничение шины PCI-Ex1 256mb\sec ?

Эффект есть даже от рейда из двух десяток сиагейтовких. А объём роли не играет, у меня все данные на домашнем файл-сервере хранятся
LAV48 29320A RAID держит, а вот 29320LPE нет...

Крокодил Геннадий
Особого смысла нет, особенно для дома, лишние траты. А скорость, да, упрется. И там далеконе 256, а меньше.

Какой-то, конечно, будет, но вот в линейном чтении небольшими блоками (а это, смею предположить, такие задачи как загрузка винды и антивирус при условии дефрагментации диска), например, контроллер 29160 уступает даже ICH7-10. Конкретно 29320LPE не знаю, не тестил, но, в принципе, это потомок 29160, может, чего и улучшили, но не факт.

maxf

у меня обратные наблюдения.

29320 - скорее не потомок от 29160, а член семьи 320-х контроллеров адаптека. Интерфейс PCI-Express обнадеживает тем, что узким местом будет не реализация PCI в ICH7-10

Ну вот мои наблюдения: http://images.people.overclockers.ru/179480.png
Видно, что SCSI на малых блоках даже хуже WD Green. Да и раптор не слишком впечатляет в линейном чтении.
Для тех, кто не доверяет HAB скажу, что эти данные в целом коррелируют с iometer (у того чуть меньше, но тесты проводились на файловой системе), только burst не мерил.

maxf

не показательно. Из опыта я вывел, что SCSI тяготеют к большим размерам блока - в районе 1MB, когда как обычные ПАТА- и САТА-накопители на таком блоке скорость уже снижают. Для них максимум достигается при размере блока в 128КБ. На маленьком блоке тормозят все. Думаю, что это особенность работы микропрограммы и драйверов. Так что в данном тесте наиболее интересно выглядят не раптор, и не Cheetah, а EADS
С другой стороны, тут в тесте явно видна линейная компонента, а обычно при чтении маленькими блоками идет случайный доступ...
Третий момент - Сигейт - действительно тот еще тормоз. Хотя бы в том отношении, что у него заточка микропрограммы под серверные задачи. Для рабочих станций с их другим характером нагрузки более подходят Хитачи или Фуджицу. Так было и, видимо, так и будет... Поэтому сигейт домой менее оптимален. Возможно что-то можно потюнить фирменными утилитами, но, думаю, что кардинально ничего не изменится. Хотя если накопитель достается нахаляву, то как известно, дареному коню в зубы не смотрят

Неинтересно, он только линейную скорость меряет.



Это где же они снижают то?
http://www.fcenter.ru/img/article/hdd/2000GB/136160.png
http://www.fcenter.ru/img/article/hdd/2000GB/136156.png
Другое дело, что за счет более быстрых пластин, на крупных блоках SAS быстрее будут. Ибо при работе большим блоком кэш особой роли уже не играет.
На мелких блоках, у SAS не слишком хорошо дела с запиью обстоят, поскольку это серверные диски, и больших сегментов кэша они не выделяют, отложенная запись у них почти отсутствует.

Я не понял, что они снижают.
Естественно, речь о режиме ЧТЕНИЕ. Как выполняется запись мне не интерсно.
По (моей) статистике следует, что XP читает блоками по 64К. Под Vista не запускал, думаю аналогично.
Любой запрос чтения большого файла рассыпается на запросы по 64К.
Блоки в 128К и более бывают только в тестах и невозможны в реальной работе. Будем обсуждать то, чего не бывает?
SCSI - да. Виноват тормохной интерфейс и, часто, тормозной контроллер. И всякие спекулятивные алгоритмы (например, включение NCQ ухудшает чтение одиночных мелких файлов) Ну как сказать ... тормоз в 25Mb/s и тормоз в 55Mb/s все-же несколько отличается.... Ну да, IDE контроллер не умничает, встроенные IDE контроллеры ближе к процессору. Потому они меньше тормозят.
Согласен. Но один момент - при работе системы позиционирования может учитываться мгновенное нахождение секторов.
В одном из тестов на fcenter по дискам IDE прозвучала примерно такая фраза - на случайных операциях этот диск показал феноменальную скорость выполнения операций. Результат означает, что диск за 1 оборот мог выполнять 2 операции. Не помню о ком, кажется WD Black ... и из-за его двухядерности.
????????????????????
Вот на что угодно, а на сервер его ставить нельзя. FW расчитана исключительно на рабочие станции и при многопотоковом доступе диск просто ложится. В 7200.12 это вроде вылечили.
Если верить замерам fcenter, то это должен быть WD RE3. 7200.12 вполне может применяться. У него чуть хуже многопотоковый доступ, но чуть лучше линейный. Впрочем, любой диск сейчас совсем не плох (кроме отдельных провальных моделей Seagate), потому особой разници дома не заметить. Для сервера разница будет ... но это не интересно.

serj

речь не про SATA, а про SCSI-накопители (в принципе, применимо и к SAS)

All
Я одного не понимаю: КАК можно сравнивать результаты полученные на РАЗНЫХ контроллерах?
serj
Всё бы хорошо, но если в одиночном режиме всё более менее ясно, то в РАЙД режиме все карты путают драйвера.
У меня сейчас есть возможность потестить SCSI, есть штук 5 (на самом деле больше, но всё, что меньше 36Гб, не считаю) дисков. Есть 10к и 15к. Есть многопоточная (практически рандомное чтение) нагрузка, есть PCI-X контроллер и соответствующий слот, есть Win2008 Server с монитором ресурсов и статистика HAB'a. Если интересно - предлагайте варианты тестирования.

HDTunePro 3.50, Random Access.



Добавлено спустя 2 минуты, 59 секунд
Если под 'разными контроллерами' имелось в виду внешние и встроенные контроллеры, то - извини, мне как-то безразлично. Производительность дисковой системы = XXX, что меньше/больше дисковой системы YYY и откровенно пофиг, какими средствами реализованы эти системы. Вопрос цены рассматривается отдельно.
Низкая надежность встроенных контроллеров - миф.

serj

Смотря как этот вопрос рассматривать. РЕЙДы на них - действительно не супер. Но как не-рейд - к ним обычно претензий нет. Кроме отдельных случаев типа несовместимости ВИА и САТА-2

Так нелинейная бывает только в специфических задачах или на сильно фрагментированном винте Вот, например, Касперский читает в основном линейно блоками по 2 Кб (что линейно - неудивительно, ибо средний размер файла куда больше 2 Кб; только если винт зас*аный, недефрагментированный, тогда будет не очень линейно ). Если винда работает блоками по 64 Кб - это уже кое-что, тут чаще будет нелинейное чтение, но и блок-то уже не маленький! Но насколько я понимаю, таким блоком она копирует, а какие-нибудь другие задачи могут производиться и другим блоком (интересно, каким блоком она грузится); у меня, например, постоянно понемногу что-то пишется и читается блоками по 2 Кб. Правда, нагрузка при этом мизерная, если только не накладывается еще что-то (как, например, на ноутах с плохим SSD, стоит только еще что-то мелкое записывать, например, логи в ICQ, это приводит к лагам системы по секунде).

диск за каждый оборот пластин успевает сделать две операции чтения.


Добавлено спустя 11 минут, 38 секунд


Вы про сканирование диска на вирусы? Если у вас винт дефрагментируется регулярно, то разумеется он (антивирус) будет линейно все читать. Только вот...Как вы часто сканируете диски на наличие вирусов? Я, например, если честно, забыл, когда это последний раз делал.



Как между собой коррелируют размер файла, и характер чтения с накопителя?


64 — это достаточно маленький блок, немаленький, это от 128 начиная.





Ну да, винда (ХР) во всяком случае, все свои фоновые операции, делает именно таким блоком, а копирование блоком по 64 к.

Ну, как бы, критические области он каждый раз при запуске сканирует. Иногда и полную делаю, если есть подозрение, что что-то подцепил. Кроме того, при обращении к файлам (при копировании, в частности) он их проверяет, но тут блок, видимо, такой, каким их считывает система или программа.


Если файл не фрагментирован и нам надо считать его последовательно целиком, то, скажем, при размере 20 Кб подряд прочитаются всего 10 блоков, а потом будет seek на следующий файл. При большом файле больше последовательных операций.
Можно даже расчет произвести: 20 Кб файл последовательно прочитается примерно за 1 мс, а потом будет seek порядка 10 мс, так что в этом случае при антивирусной проверке даже и не совсем последовательное чтение получается. А вот если файл 200 Кб (таков средний размер, кстати, в наиболее часто сканируемой и используемой папке - system32), то будет уже 50/50 (если файлы расположены плотно, то перевес будет в линейную сторону).

есть два раптора по 36 гигов старые
намного они будут проигрывать в скорости двум велосити рапторам
все хозяйство в рэйде 0

efs
да, старые рапторы НАМНОГО медленнее велосирапторов.

Заметно, к томуже это первые серии на пластинах плотностью 36 ГБ.

Provider



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

efs - они будут даже медленнее современных 7200rpm дисков.