?

Log in

No account? Create an account
Igor M Podlesny
Обнаружил сегодня в комп. магазе PCI-E x1 SATA-контроллер A-410 (STLab) 
9th-Nov-2008 06:46 pm
В связи с тем, что на системной плате у меня всего 4-е SATA-разъёма (зато 2-а PATA, и аж целых 2-а пустующих PCI-E x1) + возросшем, в связи с последними событиями ("Диски Samsung -- полное говно. Полное") уровне... эээ... "тревожности", задался вопросом "А может купить ещё диск, или пару, и забацать RAID-6?".

Правда, я не уверен ещё в этом SATA-контроллере, поскольку отзывов про него практически и нет. Кроме того, в корпусе сейчас 6 дисков (4 SATA + 2 PATA), так что единственный вариант доп. набивки это какой-нибудь Mobil Rack в 5,25-отсек (это если оставаться с тем же корпусом).

Ну и RAID-6 на 5--6-и дисках в домашнем хоз-ве смущает немного. :-) Может просто регулярный back-up на внешний USB-storage?
Comments 
21st-Nov-2008 02:59 pm (UTC) - > стабильно оказываются скорость выполнения XOR/ECC
«…
dmesg|grep xor
[ 0.137498] xor: automatically using best checksumming function: generic_sse
[ 0.153362] xor: using function: generic_sse (9224.400 MB/sec)
…» — я был бы рад, если бы диски работали, так чтобы этот xor был «ограничивающим при записи фактором». %-))

P. S. «…
[ 2.990000] raid6: int64x1 3003 MB/s
[ 3.046671] raid6: int64x2 3938 MB/s
[ 3.103341] raid6: int64x4 3431 MB/s
[ 3.160000] raid6: int64x8 2683 MB/s
[ 3.216678] raid6: sse2x1 4173 MB/s
[ 3.273340] raid6: sse2x2 5591 MB/s
[ 3.329998] raid6: sse2x4 5823 MB/s
[ 3.330036] raid6: using algorithm sse2x4 (5823 MB/s)
[ 3.330076] md: raid6 personality registered for level 6
…»
22nd-Nov-2008 03:17 am (UTC) - Re: > стабильно оказываются скорость выполнения XOR/ECC
Это же только математическая часть XOR/ECC, а не вся операция по хешированию/записи. Да ещё софтовый рейд. Не стоит забывать, что проц на компе много чем ещё другим полезным занят, помимо вычисления хеша, и наблюдать 100% занятое одно из ядер проца в момент, например, видеозахвата HDDV - грустно: в лучшем случае заканчивается просто тормозами. В худшем - потерей кадров.

Это во-первых. Во-вторых, у софтового рейда есть свои "прелести". Помимо не очень удобного пользования оным, особенно при совершении hot-swap, не стоит забывать, что после хеширования надо блоки данных запихнуть на диски, а реалии аппаратной архитектуры десктопов таковы, что распараллелить этот процесс почти невозможно - данные неминуемо проходит через общесистемную шину (Memory<=>PCI/PCIe<=>DiskController) и через шину контроллера дискового (DiskController Internal IO<=>DiskController External SATA/SAS ports<=>HDD SATA/SAS Interfaces). И пусть даже каждый диск на независимом контроллере висит (а кто такое дома видел хоть раз?) - всё равно шина до контроллеров всего одна и по ширине ограничена. Для массива из пяти дисков надо прогнать по шине как минимум в пять раз больше информации (на самом деле ещё больше, да ещё и в обе стороны - если нет кеширования или если имеет место быть cache miss), чем в случае с аппаратным RAID контроллером. Что не может не сказываться на скорости работы. Понятное дело, что с появлением PCIe с её 0.5ГБ/с для 1х соединения (1ГБ/с для PCIe 2.0) это ограничение стало менее заметно, однако для больших массивов оно очень даже ощущается.

Дальше, понятие "операция XOR/ECC" включает в себя не только математическую операцию - чтобы записать на диск новый байт (точнее, новый сектор = 512 байт) надо для начала считать со всех дисков массива сектора в количестве (число дисков)*(размер чанка рейда в секторах - обычно 128 секторов), посчитать хеш и загнать это дело на диски обратно. В худшем случае (последовательный доступ к дискам - как оно обычно получается для софтового рейда) получается, что общее время выполнения операции записи для массива из 5 дисков равно:
5*(время чтения 64Кб)+5*(время хеширования 64Кб)+2*(время записи 64Кб).
Временем выполнения операции расчёта хеша тут можно пренебречь - оно много меньше чтения и записи. Итого получаем: 5*(время чтения 64Кб)+2*(время записи 64Кб).

Пусть скорость работы 2,5" дисков меньше в 1.5 раза, чем у их больших собратьев (хотя тут есть с чем поспорить - при случайном доступе важно время поиска/доступа, а оно у мелких дисков не сильно отличается). Получаем, что массив из пяти мелких дисков будет записывать в полтора раза дольше данные. Однако в сравнении со скоростью записи на одиночный диск разница между "почти в пять раз медленнее" и "почти в семь с половиной раз медленнее" мне большой не представляется ;-D - один фиг медленно, что 10Мб/с, что 6Мб/с.

Спасением может быть серьёзный аппаратный RAID контроллер, который умеет распараллеливать работу с дисками, и у которого на борту есть баааааальшой кеш и battery backup unit к нему в придачу. Только цены на оные отнюдь не ласковые (((.

Вышесказанное - не просто теоретические рассуждения, а грустный личный опыт - сейчас живу с домашним soft raid на 4х дисках (линукс, разумеется), для хранения всякоразноважного пользую RAID5. Подключение - 2xSil3112 PCI SATA. Скорость чтения массива - ограничена в районе 120Мб/с. Очень сильно напоминает сразу два ограничения скорости: чтения одного диска х2, и максимальную скорость PCI ~133Mb/s. Скорость записи - редко когда переваливает за 12Мб/с (речь о последовательной записи больших объёмов - при мелких объёмах всё нивелирует кеш файловой системы - объём ОЗУ = 4Гб, и ядро линукса на кешировании не экономит).

На работе пришлось много общаться с AMI/LSI MegaRaid-ами и AmCC 3ware контроллерами, причём с последними в основном работал в связке с массивами на основе 2,5" SATA дисков.

Аппаратный 3ware с 512Mb кешем и BBU + масcив 4x2,5" SATA HDD 120Gb в лёгкую уделывает мой домашний soft рейд - устоявшаяся скорость записи на диски достигала 35-40Мб/с - весьма и весьма неплохо. Скорость чтения у PCI решений упиралась всё в те же 120Мб/с при хорошей погоде, у PCIe 1x контроллеров - доходила до 150Мб/с. Думаю, дорогие контроллеры с PCIe 16x и с массивом дисков на 20 могут выдать более вкусные цифры ;-D.
22nd-Nov-2008 04:21 am (UTC) - Вижу целый ряд ошибочных представлений …
… относительно Software RAID. По кр. мере, относительно Linux Software RAID (LSR).

Для начала приведу параметры своего RAID-5 на, всего лишь, 4-х дисках:

Чтение:
4294967296 bytes (4.3 GB) copied, 18.5519 s, 232 MB/s
Запись:
4294967296 bytes (4.3 GB) copied, 27.0766 s, 159 MB/s
— это всё при «current CPU frequency is 1000 MHz».

1. Большинство из нас не занимается видеозахватом HDDV. Хотя, лично я уверен, что мой нынешний RAID с этим бы справился. ;-) Вместо того, чтобы покупать RAID-контроллер, я бы лучше купил 4-х-ядерный проц. Больше кэша L2. И всё в таком духе. На сэкономленные деньги можно несколько штук купить. :-)

2. > надо для начала считать со всех дисков массива сектора в количестве (число дисков)*(размер чанка рейда в секторах - обычно 128 секторов),

«…
It appears that some hardware RAID systems have problems with large stripes: they appear to always transfer a complete stripe to or from disk, so that a large stripe size will have an adverse effect on performance. vinum does not suffer from this problem: it optimizes all disk transfers and does not transfer unneeded data.
…» — это из man vinum на FreeBSD. Уверен, что Linux'овый RAID тоже не читает весь чанк, на самом деле. А вот сколько нужно отдать денег за аппаратную контру, которая будет не настолько тупа, я могу лишь предположить. Очень «вкусные цифры» © для производителей железки, и её перепродавцов. ;->

3. > В худшем случае (последовательный доступ к дискам - как оно обычно получается для софтового рейда)

Я не вижу причин, по которым LSR не может инициировать операции чтения одновременно. Вообще, есть простой, но хороший тест, который я стараюсь выполнять, прежде, чем ожидать какие-то параметры от создаваемого RAID'а. Нужно просто запустить паралелльно несколько dd-чтений с разных дисков, и посмотреть, какой bandwidth в пр-цпе можно ожидать.

4. > не очень удобного пользования оным, особенно при совершении hot-swap

Ну это удобство зависит от корзинки, а не от типа RAID. Ибо SATA вполне позволяет делать how-swap, и мой личный опыт (не грустный :-}) это подтверждает. Единственное «но», это лампочка у упавшего диска гореть не будет «красеньким». Но зато просто не будет гореть вообще. :-) Так что найти его труда не составит.

P. S. Про то, какая жопа наступает, когда дохнет аппартный RAID, который проработал несколько лет, и на тот момент уже занесён в «красную книгу», я думаю, ты со своим опытом работы, вполне себе представляешь.
22nd-Nov-2008 05:25 am (UTC) - Re: Вижу целый ряд ошибочных представлений …
По P.S. - и не говори, до сих пор с ужасом вспоминаю 36 часов подряд на работе и исследования содержимого дисков - помер у одного клиента AMI MegaRaid старенький, к которому была прицеплена древняя же корзинка на 12 дисков SCSI 3,5". Ребус под названием "ну и как же этот долбанный контроллер перемежал RAID50 на 12 дисках" решить удалось, и загнать в аналогичный режим работы linux software raid тоже, однако повторения подобного ой как не хочется.

С остальным, по цифрам работы - меня как раз сейчас под рукой оказался сервер клиента одного, где я ваял Raid5 software под линух на 4х320Gh SATA WD 3,5".

Прогнал синтетические тестики, объём взял - 10Гб, чтобы поменьше всякие там кеширования файловой системы влияли. Для начала, синтетика "память-память":

[root@lx2srv4 Raid5]# dd if=/dev/zero of=/dev/null bs=10240k count=1000
1000+0 записей считано
1000+0 записей написано
скопировано 10485760000 байт (10 GB), 6,41618 c, 1,6 GB/c

Теперь диски:

[root@lx2srv4 Raid5]# dd if=/dev/zero of=/misc/Raid5/tempfile bs=1024k count=10000
10000+0 записей считано
10000+0 записей написано
скопировано 10485760000 байт (10 GB), 183,38 c, 57,2 MB/c

[root@lx2srv4 Raid5]# dd if=/misc/Raid5/tempfile of=/dev/null bs=1024k count=10000
10000+0 записей считано
10000+0 записей написано
скопировано 10485760000 байт (10 GB), 108,552 c, 96,6 MB/c

Серверочек старый и убогий, диски сидят на одном SATA контроллере, встроенном в чипсет. Судя по всему, PCI. В момент записи top показывал, что каждый из двух процов занят на 30-35% System и 8-10% IOWait.

Скорость работы одного из дисков на чтение (на запись как-то не тянет проверять - надо диск из рейда выводить, потом обратно засовывать, ребилд делать - морока ;-D):

[root@lx2srv4 Raid5]# dd if=/dev/sdb of=/dev/null bs=1024k count=1000
1000+0 записей считано
1000+0 записей написано
скопировано 1048576000 байт (1,0 GB), 15,0733 c, 69,6 MB/c

Выводы по скоростям:
1. Soft Raid5 даёт значительный прирост в скорости последовательного чтения, в данном случае - почти в 1.5 раза. Будь аппаратная база лучше - и цифры были бы лучше.
2. Домашние 12Мб/с на запись - странный факт, надо разбираться. Прогоню синтетику на днях, посмотрим, что она скажет.

По п.3 - LSR то почти одновременно может операции чтения/записи инициировать, только вот шина, по которой bus mastering будет обмен память-контроллер вести - как правило только одна. И хорошо, если это PCIe 1x, а не PCI. Не говоря уже о том, что сам контроллер может иметь ограничения по одновременной работе со своими SATA портами.
Методику одновременного чтения несколькими процессами с разных дисков пользую давно. Для грубой оценки и dd хватает, для тонкой есть, например, iometer.

По п.4. - с LSR таки приходится помимо замены диска ещё и вручную его в массив загонять. Лампочка - фиг с ней, можно без неё. А с аппаратным контроллером - сунул диск и пошёл себе пиво пить, а ребилд - сам собой уже пошёл.

Собственно, я ничего против LSR не имею - сам его пользую и другим рекомендую. Просто лень подсказывает, что с аппаратным контроллером как-то оно удобнее. А опыт работы говорит, что с хорошим аппаратным контроллером и цифры скоростей таки выше при меньшей загрузке ЦПУ. Цена вот только (((.

З.Ы. Кстати, вот интересную вещь ещё заметил только что на рабочей машинке:
[root@lexa2 Raid5]# dmesg | grep -E 'personal|xor|raid' | grep -v regis
xor: measuring software checksum speed
8regs : 2684.000 MB/sec
8regs_prefetch: 2592.000 MB/sec
32regs : 1920.000 MB/sec
32regs_prefetch: 1780.000 MB/sec
xor: using function: 8regs (2684.000 MB/sec)
raid6: int32x1 765 MB/s
raid6: int32x2 902 MB/s
raid6: int32x4 777 MB/s
raid6: int32x8 804 MB/s
raid6: mmxx1 1652 MB/s
raid6: mmxx2 2964 MB/s
raid6: sse1x1 1269 MB/s
raid6: sse1x2 1988 MB/s
raid6: sse2x1 2019 MB/s
raid6: sse2x2 2785 MB/s
raid6: using algorithm sse2x2 (2785 MB/s)

С какого перепуга ядро даже не пытается пользовать sse для xor - непонятно! ОСь - Fedora8, ядро - 2.6.24.7-1.rt3.2.fc8.ccrmart.
22nd-Nov-2008 05:32 am (UTC) - > С какого перепуга ядро даже не пытается пользовать sse
Я как-раз на схожую тему недавно с разработчикам общался: http://marc.info/?t=122685240300001&r=1&w=2

Только там наоборот, суть в том, что используется SSE, несмотря на то, что по скорости оно чуть хуже (почему хуже там тоже выяснилось).

H. Peter Anvin, думаю, исправит всё в лучшую сторону.

> ядро - 2.6.24.7-1.rt3.2.fc8.ccrmart.

Попробуй для начала «latest stable» — 2.6.27.7; вполне может быть, что там это уже исправлено.
22nd-Nov-2008 06:10 am (UTC) - Re: > С какого перепуга ядро даже не пытается пользовать
Честно говоря устраивать пляски со сборкой ядра - жалко времени свободного. А тем более пробовать vanilla ядра в RedHat системах. Тут ещё есть "закавыка", что мне на этой рабочей машинке нужно rt-ядро, ибо её под работу с jack/ardour частенько пользую. Попробую побороться для начала методом перебора старых/новых готовых RPM бинарных с ядрами, как rt так и обычными. А там видно будет, может тоже жалобу в mailing list закину )).
22nd-Nov-2008 06:13 am (UTC) - > жалко времени свободного.
Есть такое впечатление, что это проще, чем собирать KDE3. ;-)) Я настолько привык к самосборке ядер, что уже и не замечаю этого процесса. Компиляция у меня минут 7—8 обычно длится (поскольку .config свой, где всё лишнее выкинуто).
22nd-Nov-2008 06:19 am (UTC) - Re: > жалко времени свободного.
Без КДЕ3 обойтись - никак, а без самосборного ядра и плясками с бубном - попробовать можно ))). Вдруг сменой RPM-ок получится обойтись? Оно и ладно...
22nd-Nov-2008 06:16 am (UTC) - > нужно rt-ядро, ибо её под работу с jack/ardour
Да нет никакой заковыки:

http://rt.wiki.kernel.org/index.php/CONFIG_PREEMPT_RT_Patch
http://www.kernel.org/pub/linux/kernel/projects/rt/

Там кстати, уже 2.6.24.7-rt21 давно лежит. Так что смысл есть.

Я лично немного разочаровался в этом -rt, когда у меня nexuiz-glx заметно подтормаживал, а на обычном vanilla kernel — просто летал.
22nd-Nov-2008 06:22 am (UTC) - Re: > нужно rt-ядро, ибо её под работу с jack/ardour
От rt-ядра при соответствующем тюнинге есть толк, проверено по количеству xrun-s, которые jack выдаёт при работе с rt и без rt ядра.

Но то, что rt ядро - штука не для "десктопа общего пользования" - факт. Может, и "xor без sse" глюк - последствие этого самого rt-patch, кто знает.
Будем поглядеть, если время найду ).
22nd-Nov-2008 06:24 am (UTC) - > штука не для "десктопа общего пользования" - факт
У меня такое подозрение, что от версии к версии могут быть значительные расхождения. Впрочем, несколько -rt-версий nexuiz'ом я не тестил. :-)
22nd-Nov-2008 07:52 am (UTC) - Re: > штука не для "десктопа общего пользования" - факт
Девиации поведения от номера версии - разумеется присутствуют. Но тут скорее другого плана соображение есть против rt на десктопе (и против большей скорости работы rt по сравнению с обычными ядрами вообще): все процедуры обработки прерываний в rt ядре загнали в kthreads, включая и верхи и низы обработчиков, да ещё и гарантировали жесткую вытесняющую многозадачность (hard preemtion). Отсюда следует, что, во-первых, криворукий юзер всегда может так настроить приоритеты этих самых kthreads, что большую часть времени ядро будет проводить в процедурах обработки прерываний от сетевой карточки и звуковушки, полностью игнорируя клавиатуру и видеокарту. Или даже полный deadlock сделать, установив слишком низкий приоритет для обработки прерывания таймера/hires-таймера. Во-вторых, выделение в kthreads даром не проходит - всегда есть overhead из-за дополнительного кода и всяких там spinlocks. Ну и в-третьих, по умолчанию в нетюнингованной системе все обработчики прерываний имеют равный приоритет. А это не вполне верно, ибо если 3d пользуется, то видеокарте требуется всяко побольше ресурсов для работы, чем какой-нибудь там звуковушке или сетевушке. Со всеми вытекающими. В не-rt ядрах подобной проблемы не возникает.
22nd-Nov-2008 07:59 am (UTC) - Я так далеко не вдавался. :-)
И у меня более простое объяснение: в -rt более «гладко» работает scheduler, но это значит, что не только latency ниже (хорошо), но и производительность (плохо), поскольку чудес не бывает. То есть, иными словами, без рывков, но медленнее. :-) А вот с nexuiz'ом этим были именно рывки, и никакой плавности. Так и не понятно — то-ли regression конкретной версии, то-ли ещё что.
22nd-Nov-2008 06:33 am (UTC) - > проверено по количеству xrun-s, которые jack выдаёт
Кстати, а какую FS применяешь? XFS? :-)
22nd-Nov-2008 07:41 am (UTC) - Re: > проверено по количеству xrun-s, которые jack выдаёт
Не выпендриваюсь особо и пользую ext2 там, где надо побыстрее, но не очень важно (в частности, HDDV и просто DV захватываю именно на ext2 раздел без atime, и лежащий на md raid0 из двух дисков); ext3 под остальное и vfat на флешках и внешних USB хардах - чтобы совместимость с виндой была. tmpfs, разумеется, там, где оный к месту.

На почтовых серверах пробовал пользовать reiserfs - при большом объёме траффика работало отлично - с ext2/3 и их тормозами на куче директорий и мелких фалов не сравнить. Пользовал долго, до тех пор, пока не случились в датацентре ЧП с отрубанием питания у всех 15 серверов кластера. Дело закончилось потерей почти полумиллиона сообщений, которые в у серверов в очередях qmail висели, после чего схлопотал от начальства и увёл очереди обратно на ext3.

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

Ну и GFS редхатовский пользовал - этот вот для кластеров на серверов 16 как раз впору.

С XFS не сталкивался, но слышал смутные слухи, что его реализация на linux пока что не очень то стабильна, быстра и хороша. Или сейчас уже ветер переменился и всё прогрессивное человечество на XFS сидит? Кстати, ещё ходили какие-то слухи, что вот-вот ext4 появится и всех-всех под себя подомнёт. Не в курсе?
This page was loaded Jun 19th 2019, 4:48 pm GMT.