> А есть еще www.nag.ru и там рассказывают как оптику кусачками
> обжать. А что? Тоже решение неплохое, а главное дешевое!
Ну www.nag.ru вообще рулит не подецки! Знавал я того товарища держателя сайта. Там вообще много любопытной информации храниться. Рекомендую для новичков сходить на тот сайт. особенно для начинающих провайдеров.
> Достаточно зайти на сайт адаптека в раздел драйверы, особенно по ZCR контроллерам, и сразу становится понятным, что поддержка линукса у адаптека мягко говоря дохлая
Куда ты уже сходил? Сходи ещё раз.
Ставил Slackware 10: выбрал ядро adaptec.i и всё прекрасно работает...
2motherfucker (*) (11.11.2004 11:57:09)
>Приходи, покажу трупиков. btw, надо четко понимать что дохнут то винты одинаково. Вы просто посчитайте число идешных винтов в вашей конторе и сказевых, а потом поделите ;-)
Надо также четко понимать, что SCSI ставят в основном на сервера, а IDE/SATA на воркстейшены, где в лучшем случае LA=0.8-1.5, а на серверах до 20-ти может быть (стресс тест пускали :-))
>Ах да касаемо очереди запросов - в SATA она есть это во первых. Во вторых умные операционки делают точно то же самое и в случае одного диска вполне успешно. Вот если RAID из многих дисков там OS не пооптимизирует.
А не раскажете ли вы нам, откуда OS знает КАК лежат данные на винте и КАК может управлять процесом их считывания (позиционирование головки винта)?
LOL.
The Adaptec SCSI Card 29320LP-R is a low profile, 64-bit 133 MHz PCI-X, single-channel Ultra320 SCSI card with integrated HostRAID RAID 0/1 optimized for rack-mount servers. The 29320LP-R is a cost effective hardware based RAID, a better alternative to software based RAID in the market today
HostRAID RAID 0, 1 data protection (Windows 2000, NT 4.0 and XP only)
>Интересная статейка: http://www.wdc.com/en/library/sata/2579-001097.pdf Точно, интересная,
>Figure 1 is representative of the SATA-to-SCSI benchmarking for random I/O workloads, in this case a Web server.
А сервер БД где? понятием вэб сервера не ограничиваются.
И еще
>Figure 1. Independent Performance Testing Storage Review - Fileserver _4xRAID0_ чото не сильно вдохновляет :-)
А вот забадяжить RAID5 из 10-ти SCSI дисков для сервера БД - это без проблем :-)
>10K RPM SCSI Product A
>10K RPM SCSI Product B
>10K RPM SCSI Product C
>WD Raptor 74 GB SATA
>Figure 2. Data Transfer Performance Degradation Comparison of WD Raptor vs. Competitors' SCSI Drives
Сравниваем досю с обычным стиральным порошком? :-)
>This is expected to ship later in 2004, perha
ps 2005. At the time of this writing, NCQ has not yet shipped, so a precise assessment on NCQ performance is not possible now. However, NCQ performance is expected to be roughly equal to TCQ.
Подождем, пока NCQ полностью сделают, потом будем посмотреть :-)
>Впрочем если 0.6Tb мало, то вполне есть недорогие решения на SATA RAID5, емкостью до ~4Tb... Все что выше - уже либо самоделкины извраты, либо не SATA. :)
2anonymous (*) (11.11.2004 13:47:48)
>А не раскажете ли вы нам, откуда OS знает КАК лежат данные на винте и КАК может управлять процесом их считывания (позиционирование головки винта)? LOL.
Не, думаю, не расскажет, он про зональную запись и трансляцию нифига не слышал :-)
Сейчас SCSI и SATA с двух сторон движутся навстречу друг-другу.
Появляется стандарт SAS (Serial Attached SCSI, совместимый с SATA).
В SATA-контроллерах и дисках начинают реализовывать TCQ.
Только линуксу пока на всё это плевать, есть SCSI -- есть TCQ, нет SCSI -- нет TCQ.
На 20-и клиентов разница между SCSI и SATA практически не видна.
Реальна она видна на RAID (кстати 15krpm далеко не всегда выгодны), и при полсотни пользователей становится уже не просто очевидной, а режущей глаза :)
2anonymous (*) (11.11.2004 17:51:56)
>и при полсотни пользователей становится уже не просто очевидной, а режущей глаза :)
а также яйца крутых перцев, решивших сэкономить на SCSI и установивших SATA :-)
>У SCSI есть ещё одно преимущество, выглядещее очень скромно, но делающее SCSI дисков единственным выбором в большинстве многопользовательских решений и серверов с большой нагрузкой — очередь запросов. SCSI-диск может получить несколько запросов, после чего выполнить их и передать результат хост-контроллеру в произвольном порядке. Что это означает на практике?
>100 пользователей работают с базой данных. Каждый пользователь пытается считать свои данные. Данные пользователей, разумеется, разбросаны по поверхности дисков. Для современных дисков самое большое время — это время позиционирования головки, и для считывания 100 блоков данных в разных местах диска головка 100 раз будет перемещена в произвольное место диска. Именно когда несколько процессов одновременно работают с диском пользователь и слышит характерное «шуршание» диска, обычно сопровождающее ощутимые замедления работы компьютера при перегрузке диска операциями.
> SCSI-диск поступит умнее — он отсортирует эти 100 запросов в том порядке, в котором _ему_ их удобнее обрабатывать (с учётом того, какие данные или часть их уже есть в кэше и где в настоящий момент находится головка диска) и сделает один проход по поверхности диска, вместо псевдослучайных «дёрганий» считывающей головкой у IDE-диска. Результат — при параллельном доступе к диску множеством процессов увеличение проихводительности в разы, а иногда на порядки.
Конец цитаты. (на случай кривого форматирования текста). Вопрос: может быть существует програмный вариант подобной технологии? В reiserfs или другую продвинутую fs ничего такого не впихнули?
>Вопрос: может быть существует програмный вариант подобной технологии? В reiserfs или другую продвинутую fs ничего такого не впихнули?
Нет, потому как содержимое пластины знает только махонький чып, угнезденный на самом харде, но эти знания know how :-)
>Проблема в том, что от кэша _внутри_ диска прока ноль целых хрен десятых без реализации этого механизма _внутри_ диска.
Да и Zoned Bit Recording - ZBR никто не отменял :-)
Ну.. скажем так, LBA- адреса идут в общем-то линейно. То есть очень большие шансы, что блок 1000 и блок 1001 окажутся где-то рядом, и скорее всего на одном "цилиндре", или в крайнем случае на соседних. Так что драйвер сам может сортировать запросы по адресам блоков, "элеваторный поиск" вполне реализуем и в IDE-дисках (драйвером устройства). Ну а то что возможны "промахи" из-за ремапа секторов - так это мелочи :-)
>Ну.. скажем так, LBA- адреса идут в общем-то линейно. То есть очень большие шансы, что блок 1000 и блок 1001 окажутся где-то рядом
Ну скажем так, при рандомайзном чтении/записи вешать фсю эту статистическую подливу на CPU мягко говоря негуманно :-) X-Files рулят :-)
>Ну а то что возможны "промахи" из-за ремапа секторов - так это мелочи :-)
И о мелочи надлежит помнить (с) Булгаков
Так пусть эти мелочи и разгребают хард на пару с контроллером, за них деньги плачены, нех проц грузить, у него свои задачи есть.
с ide понятно - он либо работает, либо глючит, и тогда его выкидывают и покупают новый потому что #### не жалко. У меня вот стал scsi глючить, причем есть сильные подозрения что это софтовая а не железная проблема. Ресеты на шине периодические. Выкидывать его конечно жалко, да и начальство убьет, нафига тогда столько денег затратил, но для выяснения ошибки нужны специалисты. Есть логи в которые драйвер выдает ошибку, состояние карты итд - но это как китайская грамота. Есть инфа от lcpci, smartctl, итд. Никто из знакомых гуру не может разобраться... я писал разработчику драйвера (aic7xxx- нет ответа) Писал в список рассылки по драйверу - там все больше вопросы шлют, ответов там видать некому писать... Магазин, продавший диск воббще ничего не знает о скази (не Москва, не Питер тебе) Вернуть им диск по гарантии можно только доказав, что глюки по вине диска (а смарт между тем Ок) Кто бы еще мог проконсультировать? есть ли какие-то форумы итд посвященные скази?
нет, диск seagate Cheetah (ultra 320), контроллер Adaptec 2930U2 - раньше когда был дебиан woody с ядром 2.4. в этой же конфигурации работало без проблем, (кажется) проблемы начались когда я поставил suse 9.1 с ядром 2.6. С тех пор и ядро пересобирал, и драйвер к нему самый последний собирал, это не помогает.
Слухай, видал я такое. В смысле резеты на ранее исправном диске и на ядрах 2.6 Мне советовали установить параметры ядра cpi=noacpi, мне не помогло, но тебе, думаю поможет.
А из анализа моей конфигурации (lspci), я выяснил, что мой контроллер имеет как PCI-устройство имеет латентности в 120 мс, вместо стандартных 32!!! Беда в том, что БИОС не позволяет выставлять латентность устройств по-отдельности. Можно, конечно, поставить 128, но я не уверен, как это повлияет на производительность. Мне на моей офисной машине это не мешает. Резеты только при загрузке. Но тебе может мешать, так что попробуй и это.
OS может предполагать как лежат данные _для одного диска_ очень просто.
По номеру блока - чем ближе номера блоков тем вероятнее меньше смещений головки будет происходить.
Посмотрите например на Software RAID1 реализацию в Linux там баллансирование происходит именно по такому методу что работает весьма не плохо.
> хинт: если процу нечего делать, займем его RAID-5 :-)
ну-ну. а я вот почситал что мне экономически выгоднее купить второй xeon в сервак за 319$ чем полноценный RAID контроллер за 500-600$.
Решение в виде Intel MR/MRU/ZCR - не прделагать -плавали занаем, грузят PCI-64/66 "нипадецки". При том что на втроой проц япроцессы смигруруют если им надо будет а на RAID жедезный - нет.;-)
"вытащи один винт на этой какашке 3ware и замени другим то же самое сделай на dpt.
и в момент перерестройки raid ты поймешь разницу в производительности что dpt потеряет только 2-5% производительности
а 3ware - 50% "
Это бред. Нормальные контроллеры имеют настройку сколько ресурсов выделять на перестройку RAID а сколько отдать приложениям. Перестройка RAID вообще линейная чтение-запись так что тут SCSI преимущества не сильно помагают.
Кто знает будет ли работать если посадить на одну SCSI шину хост контроллеры с двух компов? Физически с помощью внешнего кабеля из одного компа в другой. Ну и на той же шине будет болтаться пусть пара hdd сказевых. Можно было бы отказоустойчивую систему так собрать.
Сори за меленький офтоп
2mumpster (*) (12.11.2004 6:45:08)
"а я вот почситал что мне экономически выгоднее купить"
Ну.. э... это если сервак на 2 проца максимум, юзается один, да и то так=), и мало-мало винтов. И никакого I/O =)
Я не понимаю, как это себя оправдает на машине где процов _уже_ воткнуто по полной, и они занимаются более продуктивным делом, нежели RAID5, и дискового пространства в несколько сотен гигов с соответствующим io.
> Кто знает будет ли работать если посадить на одну SCSI шину хост контроллеры с двух компов? Физически с помощью внешнего кабеля из одного компа в другой. Ну и на той же шине будет болтаться пусть пара hdd сказевых. Можно было бы отказоустойчивую систему так собрать. Сори за меленький офтоп
Когда-то по молодости делали так. Собирали дешёвую и быструю локалку MAC-PC. Обменивались друг с другом они как раз через висящий на такой цепочке SCSI-винт. Работать -- работало, но вот были какие-то ньюансы, уж не припомню...
Меня смутил фраза "Therefore, SATA as a server-to-hard drive interface has a performance advantage over SCSI", перед этим автор не упомянул то, что есть scsi-винты с 15000 rpm.
2step: если харды в дисковой стойке отдельной (со своим рейд контроллером)- то можно. а просто два контроллера на одной шине SCSI не заработают.
2anonymous:
<Когда-то по молодости делали так. Собирали дешёвую и быструю локалку MAC-PC. Обменивались друг с другом они как раз через висящий на такой цепочке SCSI-винт. Работать -- работало, но вот были какие-то ньюансы, уж не припомню..>
а вот с этого места поподробней. если можно, конечно.
Самые начальные вопросы.
1. Есть ли терминаторы на концах кабеля ?
а) если есть, отключены ли терминаторы на всех устройствах, включая контроллер ?
б) если нет, включены ли терминаторы на крайних устройствах (и только на них) ?
2. Не завышена ли скорость работы SCSI для используемого кабеля (для Ultra 160 и выше требуется кабель с повивом как минимум) ? И, вообще, что будет, если скорость понизить ?
Да будет там все работать. Нужно только на сами SCSI контролеры
разные ID поставить. Они ведь то же на SCSI шине представлены как
устройства со своим собственным ID. Ну и с терминацией шины ни чего
не попутать.
в данном случае (попытка таким макаром организовать фолловерный кластер) ничего не получится. почему: контроллер вешающийся - вешает ВСЮ шину. таким образом со второго контроллера ты до хардов не достучишся. по этой же причине во всех дисковых стойках наружу _минимум_ два канала...
> "атлоны", "RAID софтвэрный" - это о чем? Игровая консоль, что ли?
Ну и причем тут это? Или адаптек будет нормально работать только в "сервере", а домашний workstation для 29160 слишком мелкая рыбка? Увы, но в качестве серверов, на работе используем отнюдь не писишки и совсем не с линуксом...
>> Ага... Этот беспроблемный вариант (29160) до сих пор отваливается по таймауту на дуальных атлонах в 2.6.x при хорошей нагрузке, если RAID софтвэрный...
>Боец, ты бредишь, похоже. Нечего валить на один-единственный нормальный компонент в системе все грехи. У меня аж волосы подмышками зашевелились после того, как ты описал свою ситуацию.
Возможно. Только как объяснить хорошую стабильную работу, после замены на LSI? Можно, конечно, предположить что tyan не умеет материнки делать... тоже вариант, если больше обругать нечего :)
> Это очень сильно постараться надо, чтобы контроллер ТАК раком встал. Зависшая ОС к такому вряд ли приведет. Это чему-то выгореть надо, скорее всего...
Ну тем не менее вероятность такая появляется. Не зря же для таких вещей ставят многоканальные контроллеры.
> если сервак на 2 проца максимум
я где это сказал обратное?
глупо для машины за 2300 usd брать контроллер за 600 когда дещевле проц взять второй за 300. результаты будут примерно похожи.
а про точки отказа слыхал? в отказоустойчивом кластере каждая (возможная) точка отказа дублируется. а тут имеется дырка ничем не заткнутая. цена такому фоловерному чуду - ноль. хотя в качестве пионэрской поделки - вполне даже интересно :) я вот например на досуге тоже кластерами балусь, тока HPC. :)