> Все комменты "не асилил", столько чуши сразу - не могу вынести. Поэтому если кто уже на это указывал нашим красноглазым друзьям, звиняйте.

Зависть гложет, что контора больше обычной персоналки под сервак отвести не в состоянии? ;)

> Я о чём? О том, что нужно думать головой. Всегда!

Счас посмотрим, как получится...

> CPU круче, чем проц в контроллере говорите?

Мы это знаем точно ;)

> А какова пропускная способность шины PCI?

Несерьезная.

> Или лучше давайте сразу возьмём PCI-X, что бы не так страшно было. Итак, PCI-X 64bit 133MHz даст нам теоретический предел 1GB/s. 2 канала USCSI-4 по 320MB/s сожрут всю эффективную пропускную способность этой шины. Другим устройствам уже шиш! Т.е. сервак может диски молотить, но уже по сети - ни-ни? Странный такой сервак... Или вы видите как ещё организовать обработку RAID-5 на CPU не пересылая данные по PCI?

Сэр ниасилил речь про Оптероны, а также возможность наличия нескольких независимых PCI-X/PCI64-133 и однозначно независимых 1x PCIe, коих хватит на 2 гигабитных линка, или 4х - где уже речь может вестись о 10гбит оптике? Печально... скорее при грамотном подходе в лимит ОЗУ упретесь...

> (Про PCIe будете кричать тогда, когда вам в руки попадёт хоть один вменяемый SCSI-контролер на этой шине)

Што, адаптеки 8300 для говенных САТА и 8350 для средненьких скази уже не рулят? Там 8 каналов, 2Гб/с в каждую сторону. Или тут недавнопроскакивавший двухканальный ленточник на 10гбит...

> Т.е. не о 5-10% паразитной загрузке проца при переносе расчёта КС с RAID-контроллера на CPU идёт речь, а о 50-95% паразитной загрузке PCI (PCI-X) шины.

Контроллеры аппаратные, пока низачот.

> Разница собствено в чём? Или вы пересылаете по шине ровно столько, сколько нужно записать, или вы пересылаете в 2 (для RAID-1),

Чо? "Записать"? Только на программном рейде.

> 3 и выше (для RAID-5) раз больше информации.

Чоооооо? Ну это совсем неверно...

> Тем самым ставя свой сервак на колени. Осталось только ему по-самурайски голову отрубить...

Одна голова - это несерьезно... вот 16 - это куда еще ни шло ;) А самураи животы пороли, бошки им верные друзья сносили ;) Типа намек на "лучшая участь для сервера - смерть, хороший админ всегда поможет серваку"? :)

> PS. Все истории о проблемах при использовании аппаратных RAID идут либо от бедности, либо от жадности. Ну либо от глупости. Для бедных и жадных - придуман софт-RAID. Для глупых - ничего не поможет. :)

Ниасилил... какая запутанная логика... Поясняй, короче.

> PPS. И не надо говорить про SunFire x4500, это решение именно для бедных. 2GB/s Disk-Memory....

Санковский StorEdge 9990 или хьюлеттовые топовые EVA как решение для совсем уж нищих побирушек пойдет? ;)

Вопщем пока зачет ставить рано, будут дополнительные вопросы :)

>если мне не изменяет память, например, в EMC CLARiiON все RAID реализованы в софте. Самый большой CLARiiON, CX3 80, может быть до 239TB.

Сам Кларион -- это большой хардварный рейд-контроллер, в котором стоит винда :)

А ещё бы про ZFS можно было сказать - вот оно то точно говорит, что Soft Raid решения лучше. Кстати, ZFS только в Соляре и во Фре будут? На линух сиё творение пойдёт или проблема патентов?

2bulch:

>Все истории о проблемах при использовании аппаратных RAID идут либо
>от бедности, либо от жадности

либо от того что у bulch никогда небыл установлен SuSE 9.2 64 bit под 2xXeon на Promise SATA RAID SX8300 и при этом дохли диски один за другим, так как товарисч из китая написал дрова через одно место.

товарисч bulch не имеет денюжкофф на ксеон шириной в 64 бита, поэтому никогда не узнает фсей прафды о hw raid :0)

Преимущества WinModem'ов над нормальными на DSP.

Преимущества программных контроллеров Video над видеокартами.

Преимущества Realtek Ethernet контроллеров над полноценными.

Преимущества ПК над Мэйнфреймами и РК-86 над ПК.

И т.д. . Куда катится мир...

(c) opennet

Кстати эта... недавно имел жосткий секс с каким-то древнеегипетским Megaraid, к нему в RHEL4 вроде и опенсорциные дрова были, но массив не определялся ни в какую. На поддержку того хлама давно забили, гугль показал что контроллер вообще перепрошивать новым firmware'м нужно, кое на официальном сайте обнаружено не было. А я так и не смог соорудить небольшую зеркальную файлопомойку (и даже jbod, и даже raid0 не видны были) под музычку для увеселенья и смягченья гнета тяжких трудовых будней... :\\

После сего и говори, что проблем с аппаратным рейдом нет...

Доброе утро

> Преимущества WinModem'ов над нормальными на DSP.

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

> Преимущества программных контроллеров Video над видеокартами.

Де нарыл такое? :)

> Преимущества Realtek Ethernet контроллеров над полноценными.

Неужно реалтеки додумался на серваки всяким обработчикам HDMI-контента поставить? :)

> Преимущества ПК над Мэйнфреймами и РК-86 над ПК.

Давно уже. С виду не похожи, но унутре все то же самое. Называются blade-серверами.

> И т.д. . Куда катится мир...

В нежные объятья Мелкософта :) И все что вы описали (софтварные видюхи, реалтековские сетевухи, момеды на 9600 бод) придется в скором времени использовать не по собственному выбору - а потому что ничего другого под венду работать не будет ;) А для запуска "экпслорера" понадобится тот самый неокученный мэйнфрейм.

>> Преимущества WinModem'ов над нормальными на DSP.

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

Тогда уж надо сравнивать sppp, обсуждающийся в соседнем топике с цисками :)

>> Преимущества программных контроллеров Video над видеокартами.

> Де нарыл такое? :)

Копирайт в оригинальном сообщении стоял. Уточняю: преимущества S3 Trio над GeForce. Процессор быстрый -- посчитает. Как-никак 3ГГц против 500-700 МГц.

>> Преимущества Realtek Ethernet контроллеров над полноценными.

> Неужно реалтеки додумался на серваки всяким обработчикам HDMI-контента поставить? :)

Зачем чексуммы на каком-то несчастье считать если есть такой крутой CPU? Я бы ещё и проверку MAC-адресов на него навесил чтобы не простаивал зря.

какашка этот ваш софтовый рэйд ,т.к. он разваливается на раз-два-три... говорю, т.к. сталкивался неоднократно

--седайко стюмчик

господа, а давно русское слово "говно" (омириканцы гаварят "булшит". это тоже "говно" но на английском языке) стало нецензурным? а то получается, как в анекдоте, что говно есть, а слова нет :)

--седайко стюмчик

> какашка этот ваш софтовый рэйд ,т.к. он разваливается на раз-два-три... говорю, т.к. сталкивался неоднократно

"Как вы яхту назовете, так она и поплывет" (С) ;) может просто ниасилили?

2Gharik:

>После сего и говори, что проблем с аппаратным рейдом нет...

Gharik, ты видать мой пост не "асилил", снимись с ручника...

> Тогда уж надо сравнивать sppp, обсуждающийся в соседнем топике с цисками :)

Ниасилил =)

> Копирайт в оригинальном сообщении стоял. Уточняю: преимущества S3 Trio над GeForce. Процессор быстрый -- посчитает. Как-никак 3ГГц против 500-700 МГц.

Фигня какая. Давайте тогда сравним ПСП памяти на адаптере и количество потоков, одновременно обсчитываемых процом. Тогда уже сравнивать гефорс и квад Санковских Т1.

> Зачем чексуммы на каком-то несчастье считать если есть такой крутой CPU? Я бы ещё и проверку MAC-адресов на него навесил чтобы не простаивал зря.

Передергиваете, выполнение всякой фигни уменьшающей латентность связанной девайсины как раз и стоит аппаратно выносить на нее саму (либо ставить отдельный мини-проц), а не привязывать к ЦПУ - иначе выйдет как с винмомедами: вроде момед, а суть шняга колоссальная. И на hdd - идет поточная работа, с отдельными секторами никто не работает в силу очевидной невыгодности.

> > После сего и говори, что проблем с аппаратным рейдом нет...

> Gharik, ты видать мой пост не "асилил", снимись с ручника...

Не мешай мне, друг, я в печали ;) Какое нафиг "асиливание" - утро еще, я не проснулся толком :) Только бухтеть могу, да и музыку тоже жалко =)

У нас (пров) софтовый рэйд-1 года 3 стоит. Несколько раз вылетал один из пары винтов, после замены - восстановление в бэкграунде и вообще никаких траблов, тьфу-тьфу-тьфу. Нагрузка на проц совсем не заметна. Так что soft-raid рулит.

> не представляю себе как кто-то, кроме камикадзе может спокойно использовать raid0.

Ну я спокойно использую. Вопрос - для чего? На основном сервере - согласен, самоубийство (или бомба замедленного действия, если решил свалить из конторы :-) ). За неимением свободных средств на полноценный быкап взял средненький ПК, вставил в него SATA-контроллер и SATAшные, естественно, диски в количестве 4-х штук, каждый по 500 ГБ. Объединил в страйп. В сумме получилось... 2 ТБ! Операционка - на IDE-диске. Ну сдохнет SATA-диск, ну и хер с ним. Покупаем новый за день (либо лежит на полке запасной на $250), пересоздаём страйп - и снова в путь! Вероятность одновременного слёта (в интервале восстановления сервера - максимум двое суток) И быкапируемых серверов, И быкап-сервера стремится к нулю.

P.S. Инвестиций - штука баксов. Зато ежедневный архив с недельной историей :-)

> Зависть гложет, что контора больше обычной персоналки под сервак отвести не в состоянии? ;)

Давно не видел на работе персоналки в качестве сервера. :)

> Сэр ниасилил речь про Оптероны, а также возможность наличия нескольких независимых PCI-X/PCI64-133 и однозначно независимых 1x PCIe, коих хватит на 2 гигабитных линка, или 4х - где уже речь может вестись о 10гбит оптике? Печально... скорее при грамотном подходе в лимит ОЗУ упретесь...

Назовите мне контору, у которй хватит денег на нормальный сервак, со своей PCI-X шиной на каждый слот расширения, и не хватит на, хотя бы минимальный, SAN? :) У нас во всех таких машинках не SCSI- или RAID-контроллеры стоят, а FC, каждый на своей шине - клёво. Но к вопросу Hardware RAID vs Software RAID отношения не имеет. Это решение "для богатых". :)

Ну, а если это сервачок "начального уровня", то в нём, обычно, одна PCI-X (если вообще PCI-X) для интегрированых устройств, а вторая - для дополнительных. И всё! :) И тут крайне важно, как ты эту шину нагрузишь. И здесь аппаратный рейд как раз и делает свою работу, экономит ширину шины. Главное не перестараться, и не навешать на старенький и слабенький RAID-контроллер нагрузку (в виде сложной конфигурации из большого количества дисков), потянуть которую без тормозов он не в состоянии по-определению. Или не воткнуть USCSI-4 RAID-контроллер (явно PCI-X) в 32b 33MHz PCI слот.

И, наконец, "низшая ценовая категория". "Серваки" для "бедных". Собственно, персоналки с понапихаными дисками. Тут - да! Никакой Hardware RAID не нужен, так как удорожает конструкцию вдвое. :) SoftRAID спасёт отца русской демократии!

> Што, адаптеки 8300 для говенных САТА и 8350 для средненьких скази уже не рулят? Там 8 каналов, 2Гб/с в каждую сторону.

О! Таки сделали, наконец... Давно я в рассыпухе не копался...

>> Разница собствено в чём? Или вы пересылаете по шине ровно столько, сколько нужно записать, или вы пересылаете в 2 (для RAID-1),

>Чо? "Записать"? Только на программном рейде.

>> 3 и выше (для RAID-5) раз больше информации.

>Чоооооо? Ну это совсем неверно...

Что ты не понял? В случае софтверного рейда, при зеркале у тебя каждый записываемый сектор по шине пробегает дважды, один раз для записи на первый диск, второй раз - на второй; 2-кратный объём информации. В 5-том софтверном рейде, при 3 дисках, сектор читается с "другого" диска, пишется на "свой", и КС пишется на 3-й; 3-кратный объём. При 4, 5 дисках - сам посчитай во сколько раз больше. При аппаратном рейде, само собой, данный гоняются по системной шине только 1 раз.

> Ниасилил... какая запутанная логика... Поясняй, короче.

Короче - будет ещё запутанее. Длинее может тебе надо? :)

Бедные и жадные покупают RAID-адаптер исходя из цены, а не из характеристик, и админа берут на работу не того, кто шарит, а того, кто меньше зарплату попросил, хоть он о построении дисковых систем знает только из журнала "Домашний компьютер". :) Отсюда и проблемы.

> хьюлеттовые топовые EVA как решение для совсем уж нищих побирушек пойдет? ;)

Никаким боком к теме SoftRAID vs HardRAID. :) Но вообще даже начальные EVA уже вполне себе ничего. ;)

> Сам Кларион -- это большой хардварный рейд-контроллер, в котором стоит винда :)

ну, если так на это посмотреть :))) тем не менее, XOR там делается на Xeon, а не на специально заточенной под это XORилке

> Давно не видел на работе персоналки в качестве сервера. :)

Ну для кого и 575-й пролиант - персоналка :)

> Назовите мне контору, у которй хватит денег на нормальный сервак, со своей PCI-X шиной на каждый слот расширения, и не хватит на, хотя бы минимальный, SAN? :) У нас во всех таких машинках не SCSI- или RAID-контроллеры стоят, а FC, каждый на своей шине - клёво. Но к вопросу Hardware RAID vs Software RAID отношения не имеет. Это решение "для богатых". :)

Ладно, забили, речь тогда шла о pci-e, коя вовсе не для богатых. А 16 независимых линий с каждого контроллера pci-e - это ого-го на какой массивчег, а стоит - всего ничего =)

> Ну, а если это сервачок "начального уровня", то в нём, обычно, одна PCI-X (если вообще PCI-X) для интегрированых устройств, а вторая - для дополнительных. И всё! :)

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

> И, наконец, "низшая ценовая категория". "Серваки" для "бедных". Собственно, персоналки с понапихаными дисками. Тут - да! Никакой Hardware RAID не нужен, так как удорожает конструкцию вдвое. :) SoftRAID спасёт отца русской демократии!

Угу, но интуиция подсказывает мне, что простенький одноканальный аппаратный контроллер + зеркало даже на быдлороутере будет очень к месту :)

> О! Таки сделали, наконец... Давно я в рассыпухе не копался...

Давно уже сделали, полгода назад кажись в маркетах заказать можно было без проблем. Остальные вендоры (кроме areca, по-моему) только вот никак насилят, что pci-e - шина будущего.

> Что ты не понял? В случае софтверного рейда, при зеркале у тебя каждый записываемый сектор по шине пробегает дважды, один раз для записи на первый диск, второй раз - на второй; 2-кратный объём информации.

Это понятно, с сим я не спорил, и вообще то же самое толкал.

> В 5-том софтверном рейде, при 3 дисках, сектор читается с "другого" диска, пишется на "свой", и КС пишется на 3-й; 3-кратный объём.

Да неее, фигня полная! Данные идут в количестве 1 + 1/N (для контрольной суммы) + небольшой оверхэд (из-за разбивки и служебной инфы), где N - число дисков в массиве. Нафига полное дублирование слать на каждый винт массива - туда же идет только мелкий страйпик и так по очереди + избыточная crc. И все вышеперечисленное считается всего-навсего одним ЦПУ с запасом. Весь же смысл 5-го рейда в том и состоит, что круто экономит ПСП на запись хоть шины, хоть аппаратного контроллера + мощно читает + обеспечивает избыточность.

> При 4, 5 дисках - сам посчитай во сколько раз больше. При аппаратном рейде, само собой, данный гоняются по системной шине только 1 раз.

Неа, на аппаратном - 1 раз, на программном - 1+1/N. Поэтому именно 5-й программный рулит куда как больше 2-го программного.

> Короче - будет ещё запутанее. Длинее может тебе надо? :)

Вчера, когда я это писал, было проще налить, чем объяснить - быстрее бы понял :)

> Бедные и жадные покупают RAID-адаптер исходя из цены, а не из характеристик, и админа берут на работу не того, кто шарит, а того, кто меньше зарплату попросил, хоть он о построении дисковых систем знает только из журнала "Домашний компьютер". :) Отсюда и проблемы.

Не вопрос, полное взаимопонимание, все беды от жадности :)

> Никаким боком к теме SoftRAID vs HardRAID. :) Но вообще даже начальные EVA уже вполне себе ничего. ;)

Дык... конторе нужно продать немного апельсинов и забабахать собственный датацентр с автономным реактором, а то смех один - зданий куча, а реальных площадок нет ;)

> либо от того что у bulch никогда небыл установлен SuSE 9.2 64 bit под 2xXeon на Promise SATA RAID SX8300 и при этом дохли диски один за другим, так как товарисч из китая написал дрова через одно место.

bulch ставил RedHat 7.1, RedHat AS 2.1 и SLES 9 на 2хXeon многократно (12 серваков), и на 4хXeon, и на 6хXeon. И на прочую мелочь. Но пользовал при этом разнообразные Intel SRCUxxx контроллеры. Или AMI Megaraid. Или Mylex Acceleraid. И пользовал их _годами_. (единственный отрицательный опыт - Intel SRCU42X, гавно гавном, правда, говорят, в более поздних фирмварях и его поправили) :)

> товарисч bulch не имеет денюжкофф на ксеон шириной в 64 бита, поэтому никогда не узнает фсей прафды о hw raid :0)

bulch использует для 64-бит решений, как минимум, Itanium, который особых восторгов не вызывает, но лучше, чем сырые системы для x86-64. Но даже самые "маленькие" Титаниковые серваки имеют по своей PCI-X шине на каждый слот расширения. bulch втыкает туда две FC-карточки, подключается к SAN, и не жужжит по поводу проблем с дисками. ;)

Хотя вообще bulch предпочитает Sun, HP и IBM.

Ничего, что я о себе в 3-ем лице? :)

PS. будущее на десктопах - за x86-64, спору нет, но до него надо ещё дожить, и какое отношение это имеет к сервакам? :)

> Передергиваете, выполнение всякой фигни уменьшающей латентность связанной девайсины как раз и стоит аппаратно выносить на нее саму (либо ставить отдельный мини-проц), а не привязывать к ЦПУ - иначе выйдет как с винмомедами: вроде момед, а суть шняга колоссальная. И на hdd - идет поточная работа, с отдельными секторами никто не работает в силу очевидной невыгодности.

Именно к этому я и веду :)

Для дисков "всякой фигнёй уменьшающей латентность" является как раз RAID-контроллер. Современные CPU проигрывают в производительности разве что DSP-процессорам (на специализированных задачах, естественно); но это совсем не значит, что всё нужно вешать именно на них

> может просто ниасилили

могет и ниасилил, но вот питание пару раз неудачно выключалось, причем при минимальной файловой активности, и всё - рассинхронизация... посему делаю вывод - не пользуйтесь, для чего-то серьёзного.

а статьи нам разные понапишут, и что софтовая эмуляция FPU лучше, чем FPU. 3-4 года назад писали, например, что GPU к сегодняшнему дню должны себя изжить и всё должно лечь на плечи CPU... только на чьей стороне теперь правда, брат?.. :)

--седайко стюмчик

>> В 5-том софтверном рейде, при 3 дисках, сектор читается с "другого" диска, пишется на "свой", и КС пишется на 3-й; 3-кратный объём.

> Да неее, фигня полная! Данные идут в количестве 1 + 1/N (для контрольной суммы) + небольшой оверхэд (из-за разбивки и служебной инфы), где N - число дисков в массиве. Нафига полное дублирование слать на каждый винт массива - туда же идет только мелкий страйпик и так по очереди + избыточная crc. И все вышеперечисленное считается всего-навсего одним ЦПУ с запасом. Весь же смысл 5-го рейда в том и состоит, что круто экономит ПСП на запись хоть шины, хоть аппаратного контроллера + мощно читает + обеспечивает избыточность.

>> При 4, 5 дисках - сам посчитай во сколько раз больше. При аппаратном рейде, само собой, данный гоняются по системной шине только 1 раз.

> Неа, на аппаратном - 1 раз, на программном - 1+1/N. Поэтому именно 5-й программный рулит куда как больше 2-го программного.

Ты ошибаешься. Ты говоришь об оверхеде на дисках. Там да, чем больше дисков в массиве, тем меньше потери на оверхед. Я говорю об оверхеде в обработке страйпов. Чтобы записать хотя бы 1 сектор, нужно вычислить crc соответсвующего страйпа. Так? Так! Пошли по операциям:

1. Читается "немодифицированый" страйп с целевого диска.

2. Модифицируется изменённым сектором.

3. Читаются "связаные" страйпы со всех других дисков массива, кроме того, куда упадёт crc.

4. Рассчитывается страйп crc.

5. Записывается "модифицированый" целевой страйп.

6. Записывается страйп crc.

Теперь посчитай передачу информации туда-сюда. Даже если мы возьмём дикий крайний случай в 1 страйп == 1 сектор, и первые 2 шага исчезают, и всего 3 диска в массиве, то мы имеем чтение 1 сектора и запись двух == 3 операции передачи сектора по шине CPU <-> контроллер. Возьми размер страйпа в типовые 4 или 16 Мб, и типовой RAID5 из 5 дисков. Посчитай, скока информации надо прогнать по системной шине, для записи ОДНОГО СЕКТОРА.

> По типу вот этого: http://nextre.it/oracledocs/ioscheduler_03.html

Забавно. Но: The overall performance, instead, shows better reults in the first cases (with deadline).

CFQ, насколько я помню, для базы данных лучше, когда количество изменяемых блоков сравнимо с количеством просто читаемых блоков, когда же читаемых блоков больше, то deadline лучше. Это я тоже какую-то ораклёвую писульку читал, тестировали они на RHEL то ли 2.1, то ли 3. Никаких параметров CFQ сами ораклёвцы не настраивали, насколько я помню, в дефолтном ядре от RHEL уже всё подогнано, видимо.

А! Ещё! При прочтении статьи из новости вспомнил старый анекдот:

"Вот, у меня теперь машина есть, так я за день успеваю столько дел сделать! И на диагностику съездить, и за маслом в магазин, и на барахолку за деталями, и назад в СТО на ремонт и смену масла, и на автомойку, и чё-то там ещё, и ещё... Разве успел бы я всё это без машины?!"

Так и Jeff Garzik - "Вот есть у меня СофтРейд, он становится быстрее когда ЦПУ побыстрее поставишь, и если несколько поставишь, а ещё я в коде его могу бесконечно копаться, и т.п... Разве было бы мне так весело при аппаратном рейде?"

то bulch

> Что ты не понял? В случае софтверного рейда, при зеркале у тебя каждый записываемый сектор по шине пробегает дважды, один раз для записи на первый диск, второй раз - на второй; 2-кратный объём информации. В 5-том софтверном рейде, при 3 дисках, сектор читается с "другого" диска, пишется на "свой", и КС пишется на 3-й; 3-кратный объём. При 4, 5 дисках - сам посчитай во сколько раз больше. При аппаратном рейде, само собой, данный гоняются по системной шине только 1 раз.

Это только теория, теперь попробуй оценить ее реальность:

Берем твои же цифры:

> Итак, PCI-X 64bit 133MHz даст нам теоретический предел 1GB/s. 2 канала USCSI-4 по 320MB/s сожрут всю эффективную пропускную способность этой шины. Другим устройствам уже шиш!

Для начала - 2x320 = 640 - пересылка блоковая, и предел в 1GB/s вполне достяжим - значит остальным 360 вполне хватит. Более того, ethernet на серверах обычно на другой шине, да и вообще на PCI-X сидит один контроллер, это так к слову.

Теперь о скорости записи данных: 640 MB/s Для начала - это ж на сколько дисков надо писать!!! Обычно их меньше :)

Но пусть будет так, делим 640/3 ~ 210 MB/s, и первый вопрос: где ж столько данных НА НЕПРЕРЫВНУЮ ЗАПИСЬ мы возмем? Наверно мы в CERN-e на детектор ставим свой рейд? Или DVD копируем?

Да, и еще - про чтение, то что ты забыл напрочь, тут не надо читать трижды, а это более популярная операция, взять хотя бы СУБД.

Мой опыт показал, Software RAID хорошее решение во многих случаях, и загрузка не превышает 15%.

> 3. Читаются "связаные" страйпы со всех других дисков массива, кроме того, куда упадёт crc.

Это да, это засада Software Raid-5... Хорошо, что я только 0-й softraid пользую... :)

> Разве было бы мне так весело при аппаратном рейде? bulch *, отжог! зачот! :)

--седайко стюмчик

> могет и ниасилил, но вот питание пару раз неудачно выключалось, причем при минимальной файловой активности, и всё - рассинхронизация... посему делаю вывод - не пользуйтесь, для чего-то серьёзного.

UPS с малым временем переключения конечно для пионеров, вообще несерьезная штука :)

> а статьи нам разные понапишут, и что софтовая эмуляция FPU лучше, чем FPU. 3-4 года назад писали, например, что GPU к сегодняшнему дню должны себя изжить и всё должно лечь на плечи CPU... только на чьей стороне теперь правда, брат?.. :)

Они бредили, для настоящих джедаев было очевидно, что идти стоило по пути Kyro, а не бездумному наращиванию частот и тем более не по софтовому рендерингу :)

> Но пусть будет так, делим 640/3 ~ 210 MB/s, и первый вопрос: где ж столько данных НА НЕПРЕРЫВНУЮ ЗАПИСЬ мы возмем?

Легко. База данных копирует одну большую таблицу, модифицирует, старую грохает и новую на её место. Это нормально в Data Warehouse используется. Или один большой-большой апдейт. Если вы не видели таблиц на 500-600 млн записей, это не значит, что их ни у кого нет.

АВР

> LVM!
я имел несчастье зупустить LVM поверх sw raid5.
в резлуьтате потерял свежие данные.
после принудительной синхрпонизации raid - потерял fs на LVM, все sueprblocks - были девственны чисты :(

АВР

> мне не изменяет память, например, в EMC CLARiiON все RAID реализованы изменяет. без SP всё всё равно будет работать.
как и везде, реальную работу с FC делают ASIC.

АВР

> Возьми размер страйпа в типовые 4 или 16 М
бульч - типовой stripe в Linux, да и во многих дургих ОС (типа SVM Soalris) - никак не 4/16 мб - оыбчно оно равно 16, 3к или 128k.
и потом - типовой raid5 - 3диска+1 HS, никак не 5.

то Casus

> Легко. База данных копирует одну большую таблицу, модифицирует, старую грохает и новую на её место. Это нормально в Data Warehouse используется. Или один большой-большой апдейт. Если вы не видели таблиц на 500-600 млн записей, это не значит, что их ни у кого нет.

А вы попробуйте, и тогда может все же заметите что узким местом будет что угодно, но никак не запись да диск :) Да и где вы видели, даже в DWH такое количество записей? CDR что ли там держите? ;) К слову, я сейчас как раз работаю с DWH.

Но в любом случаи, если у вас есть такой объем данных, то врят ли у вас один встроенных рейд, a сравнение именно с ним, скорей уж SAN.

> Забавно. Но: The overall performance, instead, shows better reults in the first cases (with deadline).

Может они там писали в один поток на отдельный физический винт :)

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

Угу, когда запись>чтения и во много потоков - лучше cfq, когда много чтения - то deadline, он сам соптимизирует дерганья головок...

> Это я тоже какую-то ораклёвую писульку читал, тестировали они на RHEL то ли 2.1, то ли 3. Никаких параметров CFQ сами ораклёвцы не настраивали, насколько я помню, в дефолтном ядре от RHEL уже всё подогнано, видимо.

В RHEL4 cfq вообще по умолчанию идет, и как-то хитро настроенный - вполне возможно что сии параметры близки к оптимальным для сверху водружаемого Оракела.

седайко, открою тебе секрет. Софтовый рейд 1 в линкукс ВСЕГДА синкает диски если комп резко выдернуть из розетки т.к. рейд не знает оба ли диска имеют одинаковое содержимое. По-хорошему, аппаратный рейд 1 тоже должен так делать если у него нет batery backup unit, но не все это делают и поэтому иногда возникают "странные" ситуации с raid1. Учи матчасть.

> я имел несчастье зупустить LVM поверх sw raid5.
> в резлуьтате потерял свежие данные.
> после принудительной синхрпонизации raid - потерял fs на LVM, все sueprblocks - были девственны чисты :(

Я думаю стоит написать статейку, с подробным описанием что и как делалось - дабы неопытные юзеры не повторили ошибку ;)

> Ты ошибаешься. Ты говоришь об оверхеде на дисках. Там да, чем больше дисков в массиве, тем меньше потери на оверхед. Я говорю об оверхеде в обработке страйпов. Чтобы записать хотя бы 1 сектор, нужно вычислить crc соответсвующего страйпа. Так? Так! Пошли по операциям:

> 1. Читается "немодифицированый" страйп с целевого диска.
> 2. Модифицируется изменённым сектором.
> 3. Читаются "связаные" страйпы со всех других дисков массива, кроме того, куда упадёт crc.
> 4. Рассчитывается страйп crc.
> 5. Записывается "модифицированый" целевой страйп.
> 6. Записывается страйп crc.

> Теперь посчитай передачу информации туда-сюда. Даже если мы возьмём дикий крайний случай в 1 страйп == 1 сектор, и первые 2 шага исчезают, и всего 3 диска в массиве, то мы имеем чтение 1 сектора и запись двух == 3 операции передачи сектора по шине CPU <-> контроллер. Возьми размер страйпа в типовые 4 или 16 Мб, и типовой RAID5 из 5 дисков. Посчитай, скока информации надо прогнать по системной шине, для записи ОДНОГО СЕКТОРА.

Эта... страйп в 4/16 метров убьет любой контроллер, типовой предлагаемый - 64к на любой железке, да и сам подумай - нафига такие размеры при кэшах винтов <=8Mb и файле куда меньшего размера...

Описан случай дозаписи-перезаписи отдельных секторов на случайном вводе-выводе, для 128 секторов (полный страйп) - та же самая фигня, что элементарно подтягивается включением выравнивания записи файла на ФС.

...повторим теорию + еще кое что...

Шина pci-e - полнодуплексная, можно и читать и писать одновременно, данные размазаны, есть кэш в оперативке и мы говорим о записи таки приличных объемов данных (нефиг ставить рейды на офисные персоналки).

Для достижения максимальной скорости записи писать лучше полными линейками на все винты в массиве, ежели данных нет/нет sync'a/не пришло еще время писать на винт - линуха ждет, если они поступили - пишет линейку, если синхронизация - тоже пишет, тут даже "интеллект" скази не особенно к месту.

Случай 1: самый правильный, новая линейка страйпов убивает шаги 1-3 и пишется с указанным мной оверхэдом - на записи толстых потоков так будет и так и есть, данные Die-hard сие косвенно подтверждают (самый хороший вариант для raid5);
Случай 2: самый хреновый, модификация 1 сектора в каждом страйпе линейки, тут мы: читаем все сектора разом, меняем сектор в каждом страйпе, пересчитываем CRC, пишем все обратно => оверхэд по числу винтов - это то что описали вы;
Случай 3: нечто среднее - зависит от числа модифицируемых секторов, но всяко - считанные сектора успеют обработаться ЦПУ и записаться обратно чуть ли не на следующем обороте винта, лишь бы драйвер умел такие оптимизации делать.

В общем, закономерный вывод: нужно брать и тестировать, потом тюнить систему под задачу, иначе спорить толку нет :))

Чертовы дефолтные настройки... хочу WYSIWYG на ЛОРе, ептель %)

> UPS с малым временем переключения конечно для пионеров, вообще несерьезная штука :)

Gharik, мы о качестве софтверного рэйда говорим. Вы помните? вы ещё тут предложите софтверный упс! бу-га-га, смеялся!

--седайко стюмчик

> Gharik, мы о качестве софтверного рэйда говорим. Вы помните? вы ещё тут предложите софтверный упс! бу-га-га, смеялся!

Влехкую, называется ZFS, работает от соляры ;) И вообще, хз как у вас питание отключается, может методой КЗ на всю ферму =)

> Да ладно гнать про "хардварные переключатели а-ля рбильник".

уважайте собеседника хоть немного, а? =)

> У нас на EC-овских терминалах была клавиша <Рус/Лат>.

такое я тоже застал. =) это уже гораздо более развитая техника была.

---vk

> За неимением свободных средств на полноценный быкап взял средненький ПК, вставил в него SATA-контроллер и SATAшные, естественно, диски в количестве 4-х штук, каждый по 500 ГБ. Объединил в страйп. В сумме получилось... 2 ТБ!

Если это быкапный сервер, то почему не RAID5? ну было бы на четверть меньше места, при несравнимо большей надежности. А на производительности при характерных для бэкапа нагрузках оно не сказалось бы, это ж вам не СУБД.

Лучше бы этот Jeff Garzik сделал поддержку в линухе (2.6) fake рейдов. Смешно право: 95% мамок имеют эту возможность и под оффтопиком она широко ипользуется. А под линухом, со стороны разработчиков, кроме невнятного бреда, что это дескать хреновые рейды, ничего не слышно... А тема достаточно актуальна и востребована - даже на LOR есть соотв. фак 8). По поводу всей выше разгоревшийся полемики могу сказать одно: софтовый рейд хорош только в случае самых простеньких конфигураций, 3-4 диска в raid0/linear. bulch прав, говоря о загаживании шин софтовым рейдом 5/3/1 (и их производными). Но если очень сильно хочется/поджимает - то можно 8).

Кроме того, ни один постер не осветил след. момент: "железные" рейды могут делать плановые верификации массивов, практически не снижая производительности системы. Ну и не только это - зависит от контроллера.

Я очень давно имею "счастье" возиться как с одной, так и с другой стороной медали. Если не рассматривать сказевые контроллеры (это отдельная песня), то пожалуй лучшим выбором будет 3WARE 9550SX/SE - PCI-X/PCI-E соотвественно. Promise однозначно в топку - кроме постоянных сбоев и недоразумений от него хрен чего дождешся. Если нужен raid6 - adaptec 2820SA. Корзина SATA с хотсвапом уже не проблема. Оба девайса имеют нативную поддержку в ядре.

>уважайте собеседника хоть немного, а? =)

Ладно, верю что у вас было такой "хардварное" переключение ;)

У меня нечто подобное было в роботроновском лепестковом принтере ;) Шоб перейти на русский язык ... надо было "ромашку" поменять на "с русскими буквами" ;)

Фиг ли толку с тех "рейдов", если они жрут ОЗУ и делают то же самое абсолютно, что и софтовый, только при этом еще и в ядро требуют пихать кучу всякого дерьмища, плюс формат данных на железе будет определяться вендором. Оно того не стоит однозначно, ниша у них одна - "простенькие конфигурации", да и raid5 недорейдами почему-то не держится.

А кто-то до сих пор ставит рэйды без batery backup unit?

Примочка стоит не дорого, а вот нервов сэкономит массу.

>>>Фиг ли толку с тех "рейдов", если они жрут ОЗУ ....

Был на то ответ прост... (с)

Вы забываете о тех, кто держит например вынь+лин+... Насчет рейдов5 информация устарела - многие новые мамки (там где количество SATA портов >4 ) держат. Насчет формата данных: появилось множество утилиток для перестройки рейдов после переноса с одного контр. на другой. Кроме того, биос некоторых контр. имеет аналог этих утилиток - импорт рейда. Хотя, например, переезд на домашнем компе с SiliconImage на nForce (raid0) произошел без напряга - указал тот же размер страйп блока и все поднялось.

Насчет пожирания ОЗУ говорить не приходится - так как их нет попросту в природе (для ядра 2.6, а в 2.4 жрали не больше того же софтового рейда - да оно вобщем-то и понятно). Кроме того, гораздо удобнее оперировать сразу готовым девайсом, чем создавать его через md*.

> А кто-то до сих пор ставит рэйды без batery backup unit?
> Примочка стоит не дорого, а вот нервов сэкономит массу.

Представьте себе, домашние лемминги на встроенных в мать контроллерах делают рейды без батарейки. Потом бегут на ЛОР жаловаться. И куда ее на той мамке сувать, эту батарейку? ;)

>Лучше бы этот Jeff Garzik сделал поддержку в линухе (2.6) fake рейдов. Смешно право: 95% мамок имеют эту возможность и под оффтопиком она широко ипользуется. А под линухом, со стороны разработчиков, кроме невнятного бреда, что это дескать хреновые рейды, ничего не слышно...

Вызывающе неверная информация

man dmraid