LINUX.ORG.RU

Cubieboard2 + hardware SATA RAID

 , , ,


1

3

На фотографии:

  • Cubieboard2 и
  • внешний RAID-массив CFI-B4043JDGG (JMicron JMB394). Внутри - четыре диска Seagate ST4000VN000 по 4 TB каждый, объединённые в RAID5.

Питание для кубиборды берётся от внутреннего блока питания RAID-массива.

Тут недавно кто-то интересовался пропускной способностью SATA-порта у A20 (или A10? не помню...), так что это я решил затестить в первую очередь. Результаты сравнения скорости работы с RAID-массивом по SATA с ноутбука (eSATA) и с cubieboard2:

************************************************************
* Ноутбук ThinkPad W520
************************************************************

# hdparm -Tt /dev/sdb

/dev/sdb:
 Timing cached reads:   17510 MB in  2.00 seconds = 8761.82 MB/sec
 Timing buffered disk reads: 714 MB in  3.00 seconds = 237.88 MB/sec

# dd if=/dev/zero of=/dev/sdb bs=1024000 count=10240 oflag=direct conv=fdatasync
10240+0 records in
10240+0 records out
10485760000 bytes (10 GB) copied, 43.6447 s, 240 MB/s

# dd of=/dev/null if=/dev/sdb bs=1024000 count=10240 iflag=direct
10240+0 records in
10240+0 records out
10485760000 bytes (10 GB) copied, 41.0618 s, 255 MB/s

************************************************************
* Cubieboard2
************************************************************

# hdparm -Tt /dev/sda

/dev/sda:
 Timing cached reads:   836 MB in  2.00 seconds = 417.81 MB/sec
 Timing buffered disk reads: 364 MB in  3.01 seconds = 120.90 MB/sec

# dd if=/dev/zero of=/dev/sda bs=102400 count=102400 oflag=direct conv=fdatasync
dd: warning: partial read (28672 bytes); suggest iflag=fullblock
102399+1 records in
102399+1 records out
10485686272 bytes (10 GB) copied, 337.252 s, 31.1 MB/s

# dd of=/dev/null if=/dev/sda bs=1024000 count=10240 iflag=direct
10240+0 records in
10240+0 records out
10485760000 bytes (10 GB) copied, 60.7216 s, 173 MB/s
На кубиборде стоит юзерспейс от arch linux ARM с ядром 3.4.67+ от cubian. Перед тестом и на ноуте и на кубиборде я выставил cpu frequency scaling governor в performance, чтобы частота всех ядер процессора была максимальной.

Вывод: скорость записи - УГ, скорость чтения - вполне неплохо. В принципе, ожидаемо для чипа, заточенного под «смотрелку мультимедии» =).

>>> Просмотр (1280x853, 1081 Kb)

Deleted

Проверено: JB ()
Последнее исправление: JB (всего исправлений: 3)

Ответ на: комментарий от blind_oracle

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

Нет, это ошибка именно чтения, запись то может быть корреткно отрапортована. Только в RAID6 целостность блока можно контроллировать и исправлять ошибку по избыточным данным, а в RAID5 - он в единственном экземпляре.

Второе: много у кого видел энтерпрайз? на гринах же рейды собирают. А там 10^14 и уже не 1250, а всего-лишь 12Тб, а на самом деле еще меньше, если распределение вероятности по нескольким дискам посчитать.

Я как бы за тебя очень рад, но мне «отребилженный 100% UUUUU» пятый рейд с битыми архивами не греет как-то душу. Пусть хоть 3 раза успешно отребилдится, все равно за бекапом лезть.

BaBL ★★★★★
()
Ответ на: комментарий от BaBL

Нет, это ошибка именно чтения, запись то может быть корреткно отрапортована.

Я имею в виду любое I/O, как чтение так и запись. Контроллер может определять «живость» данных только по тому, что ему рапортует диск. Если диск рапортует что сектор прочитан, контроллеру приходится верить :) Есть исключения:

Только в RAID6 целостность блока можно контроллировать и исправлять ошибку по избыточным данным, а в RAID5 - он в единственном экземпляре.

А вот тут как раз дело не в количестве экземпляров четности. В RAID6 юзается два разных алгоритма расчёта, первый страйп четности это обычный XOR аля RAID5, второй - гораздо более сложный. Но даже это не даст тебе выяснить, где однозначно ошибка.

Смотри, есть у тебя блоки A, B, C, P, Q (A-C данные, P/Q четность). При чтении (или проверке) контроллер заново считает четность и сравнивает ее с P/Q, видит что не сходится. Но ошибка может быть как в самих блоках четности, считаных неверно, так и в блоках данных, однозначно не скажешь.

Но тут есть другой режим работы RAID6 - Reed Solomon, разновидность ECC который в теории позволяет как раз такие ошибки отлавливать.

Вот тут есть какая-то научная работа на эту тему: http://web.eecs.utk.edu/~plank/plank/papers/CS-96-332.pdf

У меня в рейд-контроллере Adaptec рейд6 как раз создан алгоритмом Reed-Solomon, но как оно сказывается на работе и ловит ли какие-то глюки сложно сказать.

blind_oracle ★★★★★
()
Ответ на: комментарий от Slackware_user

а порт мультиплаер на куби есть?

Does the Cubieboard support SATA port multipliers and what is the max limit of a SATA hard disk drive?

A10 does not support port multipliers. Storage limit is per SATA 2.0 specifications, 48 bit LBA addressing or 128 PiB. To connect more disks, you would need a SATA cabinet that does RAID by itself. So the multiplier needs to emulate a single drive. The host system Cubieboard then sees only a single SATA disk, with whatever capacity your chosen RAID level gives you.

Deleted
()
Ответ на: комментарий от ncrmnt

У тебя что-то с сатой.уменя на даче первая куюиборда быстрее пишет безо всяких рейдов на 2.5 веник. Ну либо с конфигом.

И какие у тебя цифры получаются на запись? Возможно тут какая-то хитрая несовместимость контроллера в SoCе с контроллером в RAIDе. Я не пробовал тестить с отдельным диском.

А виснет - выстави гавернора в перформанс или фентези. У меня на 3.4 на стике под 3д принтер на ондеманд зависоны сразу как начинают работать движки, хотя питание раздельное и все экранировано. После мата подозрение на него, так как на перформансе зависоны уходят.

У меня оно всю неделю стабильно работало, а вчера опять зависло. Непонятно в чём именно проблема. Всю неделю работало с ondemand. У меня всё-таки подозрение на перегрев. Надо будет найти где-нибудь радиатор...

А что за «фентези» такое?

Deleted
()
Ответ на: комментарий от x_hash

На запись может быть маленькая скорость, потому что «аппаратный» рейд тормозит в режиме Raid5 (а вовсе не кубик). Попробуй Raid10 или 0.

Переделал на RAID10 и ничего не изменилось. Цифры практически такие же что при тесте с ноута, что с кубиборды.

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

Тогда бы и с ноута тормозила запись, чего я не наблюдаю.

Deleted
()
Ответ на: комментарий от SI

ты не то меряшь - померь скорость копирования с диска через ethernet ( samba ). У меня больше 20 мгбит не получалось.

Я потестил NFSv4.

Файл с рандомным содержимым на 10 GB копировался с десктопа из tmpfs на кубиборду и обратно. Результат:

  • На кубиборду: копирование 76.6 мбит/с, CPU idle ~50%.
  • С кубиборды: копирование 87.8 мбит/с, CPU idle ~70%.

iperf и туда и обратно выдаёт ~92 мбит/с.

Deleted
()
Ответ на: комментарий от AVL2

Небось еще и топ при копировании показывает 100% загрузки ядер.

Не 100, к счастью =).

Deleted
()
Ответ на: комментарий от Deleted

мде.. жалко.

а вообще arm с нормальным сата было б неплохо.

Slackware_user ★★★★★
()
Ответ на: комментарий от Deleted

Со скоростью сорвал, на 2.5 веник у меня тормознее сильно, чем у тебя. Попутал с другой железкой.

echo performance > /sys/devices/system/cpu/cpu0/cpufreq/scaling_governor

Фирменный аллвиннеровский гавернор для отзывчивости гуя на планшетах и одновременной экономии батарейки.

ncrmnt ★★★★★
()
Ответ на: комментарий от Deleted

На аллвиннерах кстати жручий до CPU wemac, насколько знаю.

ncrmnt ★★★★★
()
Ответ на: комментарий от Deleted

Нужна малошумная торрентокачалка и хранилище для бэкапов.

Двухдисковый d-link dns-320 за 100$. Там только надо кулер заменить на бесшумный. Недавно помогал аккуратно заколхозить приятелю кулер на 70мм вместо штатной 40-ки. Качает торренты, не шумит. Видосы смотрит по dlna на телеке samsung. На него (d-link) ставишь дополнительный софт и все. Мануалы ищутся быстро.

andrew667 ★★★★★
()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.