да, дисков кстати четыре, там в конфиге показывается..

Да что-ж это за южный мост то такой шустрый у Вас там, что такие скоростя умеет?

материнка вот такая http://www.supermicro.com/products/motherboard/xeon/c202_c204/x9scl.cfm . чипсет интеловский. сервер в бою сейчас...

Такс... Стоп, назад машина!

dd if=/dev/zero of=/dev/md2 bs=10M count=700

oflags=direct - не вижу флага, вы часом не в RAM пишете то? Уж больно скоростя дикие... Может оттого Ваши недоумевания? Может у Вас там ОЗУ дофига...

тьфу, может вы и правы.

Да я смотрю уж больно дикие скоростя. Тут лет пару назад мы на ЛОРе выяснили почему у меня скорость записи не велика, и откопали доку, где на ICH 9R чипсет, максимум это 80 МБ/сек - при самой-самой лётной погоде в raw режиме. Я не думаю что за пару лет технологии столь далеко ушли. - Тем паче ваша мамка довольно бюджетная.

с другой стороны, я помню что перед тем как я поставил 7Гб писаться, у меня были действительно дикие скорости. и я помню что 7Гб и 14Гб сильно не отличались в скорости, а на сервере 8Гб оперативки. соотвественно, 14 никак не могли быть в оперативке. 7Гб были выбраны за то что время теста порядка 30-40 секунд.

но вот за то что я верно помню, я не поручусь. а про флаг я не знал, млин.

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

Дык оно пока то, что Вы начали писать в начале ближе к концу скидывает на диск, а Вы продолжаете всё также писать в ОЗУ... - В общем без флага не релевантны результаты. ИМХО конечно.

с третьей стороны, ведь sata3 6Гбит в секунду, что даёт нам порядка 750Мбайт в секунду гипотетически.

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

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

короче, дело тёмное. но разбираться таки придётся..

В общем без флага не релевантны результаты.

да, согласен, результаты полностью ненадёжны.

В общем ждём обновлёных результатов! Весьма интересно посмотреть кореляцию между размером чанка и скоростью. Ну то, что Вы сплошняком по 10 мб пишете, тоже конечно тот ещё вопрос, ну да это Бог с ним, общую картину думаю можно посмотреть, но я лично бы писал блоками по 4096kb - если мне память не изменяет, именно так пишет и читает файловая система ext4 по-умолчанию.

Попробуйте блоками по 4k ещё зарубить с этим флагом, будет я думаю наиболее близко...

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

Блин... Сори но вот чего я ещё то подумал: мало того, что нужно писать с флагом и размером 4к, всё же не помешает ещё создать и файловую систему, и писать не в /dev/md2 напрямую, а в ФС - в файл, да не просто в абы какую, а в нашу - в классическую ext3/4. - Потому как журнал это не что иное как: некая часть файловой системы куда она пишет некую информацию о транзакции, а следовательно - это также будет гонять головы винчестера туда-сюда - ИМХО это будет ещё более близкое тестирование. Ну и я так понимаю, что чем больше чанк, тем больше данных оно будет синкать после сбоя питания, что тоже не есть хорошо. А с тем учётом, что файловая система имеет свойство фрагментироваться, то задетых чанков может оказаться несколько и будет оно гигабайты гонять...

честно говоря методологически я всё таки не согласен. я думаю что «чистый» вопрос всегда будет отличаться от «рабочего». в том смысле что я бы для теста раида писал бы 10Мб блоками просто на устройство. без выпендронов. а потом бы с 3 характерными для раида. параметрами померил бы производительность фс (уже тестами специфичными для фс). замер производительности фс сам по себе дело гиблое.. большие файлы или мальеникие? каталоги? много или мало? создавать или удалять? в общем я думаю вы меня понимаете. поэтому собственно и выбрал большие куски, что именно выяснить влияние в на «чистую» запись. и оно меня удивило :), но как выяснилось возможно, собака не там рылась куда я глядел..

Всё верно, я то интересуюсь потому, что мой use case это: rdiff-backup, а следовательно: это ппц. Это во-первых файловая система сверху, во-вторых: приняли чанк, прочитали предыдущий файл, сравнили контрольную сумму в чанках - записали в новое место, если различаются - записали в diff старый чанк. - В общем ужасть та ещё. Ну вот и интересно хотябы просто на файловой системе какая будет просадка. rdiff ясное дело ещё ощутимую нагрузку даст. Но всё же...

и всё таки, вспоминая тестирование.. когда всё помещалось в оперативку, ответ отдавался в течении нескольких секунд. поэтому я и брал большие размеры. и размеры я пробовал сильно бОльше, и выбрал 7Гб потому что скорость не отличалась от значительно бОльших размеров.

плюс, поглядите на скорость чтения в тесте: ведь она тоже 380Гб. а она точно с девайса идёт (ведь файловой системы нет, кешировать некому). что вполне неплохо согласуется со скоростью записи.

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

В общем ужасть та ещё.

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

Да, с этим вопросов не возникает. Я провёл тестирование rdiff-backup на ФС без RAID, потом проведу и с RAID, ну в общем ждёмс новых результатов. :)

речь идёт о нескольких террабайт данных.

ZFS(onLinux).

Раз уж вы сюда заглянули, может подскажете вот чего: есть-ли во FreeBSD какое-либо средство на подобии bitmap в mdraid? Сейчас храню порядка 4tb данных, и не очень приятно когда оно при пропадании питания начинает пересборку ВСЕГО массива. - Речь о geom mirror. Там не свежие дистрибутивы, по-этому zfs нету там.

zfs on Linux оно хорошо конечно но... : http://habrahabr.ru/post/153461/

Спросите здесь: http://forum.ixbt.com/topic.cgi?id=11:44215-131

Они не одну собаку съели на этом.

Сейчас храню порядка 4tb данных, и не очень приятно когда оно при пропадании питания начинает пересборку ВСЕГО массива.

При пропадании питания и последующего его восстановления ZFS не делает пересборок и даже сканирования массива, а просто откатывает своё состояние до последней валидной транзакции. Файловая система всегда остаётся в непротиворечивом состоянии, пока живы носители. Даже деградирующий носитель не способен вывести из строя весь избыточный массив, так как у ZFS есть статистические счётчики по каждому LUN'у, методы определения и восстановления «теряемых» данных — на выходе из массива всегда целостные данные. Для md-raid метод адекватности данных внедрён для mirror-массива сравнительно недавно, до этого можно было получать кашу из данных и считать их валидными. После потери избыточности при отказе ещё одного носителя ZFS останавливает свою работу во избежание дальнейшего разрушения массива.

Насчёт geom mirror не скажу — у меня небольшой опыт его использования.

Не очень понял что конкретно там читать, но как понял - про zfs не очень хорошие отзывы.

она точно с девайса идёт (ведь файловой системы нет, кешировать некому).

Девайс - тоже файл в своей ФС в той ОС, в которой ты тестируешь, поэтому ты не прав. Девайс у тебя тоже кэшируется.

Пруф:

rain@elitebook:~$ sudo dd if=/dev/sda of=/dev/null bs=32M count=10
10+0 записей считано
10+0 записей написано
 скопировано 335544320 байт (336 MB), 3,84634 c, 87,2 MB/c
rain@elitebook:~$ sudo dd if=/dev/sda of=/dev/null bs=32M count=10
10+0 записей считано
10+0 записей написано
 скопировано 335544320 байт (336 MB), 0,219647 c, 1,5 GB/c

vg@mua:~$ sudo dd if=/dev/sda of=/dev/null bs=32M count=10
10+0 records in
10+0 records out
335544320 bytes (336 MB) copied, 4.57073 s, 73.4 MB/s
vg@mua:~$ sudo dd if=/dev/sda of=/dev/null bs=32M count=10
10+0 records in
10+0 records out
335544320 bytes (336 MB) copied, 0.211126 s, 1.6 GB/s

Ха, и то правда. Кешируется.

И кстати, у меня всего 3gb RAM памяти! А и то вон оно без проблем всё в ОЗУ и залезло.

Там нужно не читать, а задавать конкретные вопросы по теме и внимательно читать даденые на них ответы. Всё остальное — чужие проблемы.

336 MB

всего 3gb RAM

без проблем всё в ОЗУ и залезло.

Ну я не Вам писал, а писал для AndreyKl, т.к. у нас с ним беседа была где он сказал: что у него в сервере 8гб. памяти, а он копирует мол большие файлы, и врядли оно в ОЗУ помещается. В общем тут как планировщик i/o думаю разрулит так и будет.

Спасибо Вам за тест что и с raw устройства кеш происходит. Весьма интересно.

Усёк, спрошу.

Я просто процитировал то, что прочитана часть файла устройства сильно меньшая, чем размер ОЗУ, поэтому почему бы ей и не быть кэшированной?

да, ты прав.

но вот 1.5Gb/sec это как раз так скорость которая меня пугает и по моему меня напугала. а вот 350M от четырёх дисков мне не кажутся фантастикой, тем более что у тебя с одного диска получается под 90, а 90*4 = 360. если у меня просто диски получше, то всё вполне сходится.

да, но кешированая скорость - 1.6GB/s, и если мне не изменяет память вот такая она какаято и была. а скорость одного диска у вас получается 73.4. если просто умножить на 4, то это 292, что близко к моему результату. конечно остаётся вариант с частичным кешированием.в целом, конечно, нужны новые тесты.

В общем, попросту в следующий раз на всякий случай дропай кэши. Ну и direct-чтение/запись делай, само собой.

да, я понял, спс.

Вообще, если там не будет системы, а только бекап, то, вроде как, есть такая фитча как ( http://linuxshare.ru/docs/admin/ud_sraid.html ) safe_mode_delay, по-идее md может писать это состояние в метаданные при переходе в/из, а при внезапном ребуте, если raid был в clean, то и проверять его не зачем. Насколько это реализовано на практике, я хз. Самому интересно.

Что ты можешь сказать про мой пост выше?

И ты что можешь сказать про мой пост выше?

safe_mode_delay, по-идее md может писать это состояние в метаданные при переходе в/из, а при внезапном ребуте, если raid был в clean, то и проверять его не зачем.

с bitmap это всё не нужно.

Я вопрошал касательно того, правильно ли я понимаю механизм работы. У меня есть ощущение, что clean - это просто статус, который никуда не пишется и от которого ничего не зависит.

Программный RAID-1

Всем привет! Я два дня уже убил без результатов. Установил Debian 6.0.6 на программный raid-1 массив. Установилось все отлично, но после перезагрузки «mdadm no devices listed in conf file were found» и выкидывает в busybox.

Перерыл инет, нашел решение: Добавить «sleep 10» в файл /usr/share/initramfs-tools/init после line log_begin_msg «Mounting root file system...»

А как это сделать? Я же в busybox, а там ничего нету, через LiveCD загружался а что дальше там делать я не понял.

Возможно что в вашем debian 6.0.6 mdadm (как и любой софт) очень старый.

Ну да вот полтора года назад вышел релиз mdadm 3.2.1 (сейчас уже есть 3.2.5), а в debian 6.0.6 http://packages.debian.org/ru/squeeze/mdadm 3.1.4 которому наверное больше двух, а то и трех лет.

Перерыл инет, нашел решение: Добавить «sleep 10» в файл /usr/share/initramfs-tools/init после line log_begin_msg «Mounting root file system...»

А как это сделать? Я же в busybox, а там ничего нету, через LiveCD загружался а что дальше там делать я не понял.

Это нужно загружаться в livecd. Монтировать старый каталог, в него делать bind dev proc sys примерно так:

mkdir /mnt/DEBIAN

mount /dev/sdXY /mnt/DEBIAN

for f in proc sys dev; do mount -o bind /$f /mnt/DEBIAN/$f; done

Затем chroot /mnt/DEBIAN. Редактировать из консоли нужный файл и пересоздать initrd для вашего ядра - а как это делается я не знаю (вероятно что любое обновление ядра и ваш дебиан не загрузится, нуж но будет проделывать все заново)

Спасибо за ответ. Причина точно в этом? А как сделать чтобы при установки Debian 6.0.6 он подхватил новый mdadm 3.2.5 из сети или диска ?

Не получилось. При команде mount /dev/sda1 /mnt/debian пишет unknow filesystem type 'linux_raid_member'

Так монтировать нужно реид, не знаю как оно там в реидах файлы называются.

в рейдах md0, md1 и т.д. но так тоже не работает, если mount /dev/md0 /mnt/debian

Вобщем я разочаровался в Linux. Не знаю как быть теперь.

Вопрос решил проще: Установил Ubuntu Server 12.10 Там все с рэйдом в порядке.

ССЗБ. Сервера должны быть LTS