Сказ о том, как поднимался упавший fake RAID 0

[@ForeverLive]

Очень мощно написано. Я испугался тех изображений…

[@dimavs]

A про RAID 5 не напишете? ;-)

[@PingWin]

С RAID5 будет куда сложнее, но тоже решабельно :) Имхо, проще готовую тулзу найти, наверняка есть.

[@fzfx]

=) если и да — то не скоро. если б не мои косяки — я бы и эту статью не написал.

[@merlin-vrn]

Честно — бросил читать с места «для восстановления RAID0 достаточно узнать, который из дисков первый».

Не знаю, как устроен NVidia fake-RAID 0, но Linux Software RAID0 устроен так: каждый из дисков можно использовать сам по себе, «без RAID», поскольку они идентичны. Совершенно пофигу, какой из них первый, какой второй, какой третий — на них всех (сколько ни объединишь) хранится ровно одна и та же (полезная) информация, а метаданные при «починке» деградировавшего RAIDа восстанавливаются сами собой.

Кстати, и LVM использовать совершенно необязательно. (Если хотите аццкой производительности, то как раз не использовать обязательно. Зато теряете в гибкости.)

См. также www.tldp.org/HOWTO/Software-RAID-HOWTO.html (официальная документация по Linux Software RAID)

[@merlin-vrn]

Да, кстати, и «просто так» такой RAID не расформируешь. То, что раздел — часть RAID хранится в виде типа раздела (помимо Linux Swap 0x82 и Linux 0x83, есть Linux RAID Auto 0xfd, а ещё Linux LVM 0x8e)

[@merlin-vrn]

Упс. Точно. Простите меня, хабрачеловеки.

/me посыпает голову пеплом

[@RealManPMI]

Я очень хорошо запомнил в чем разница между RAID0 и RAID1 после прочтения следующей цитаты на bash.org:

sterano: Whats the difference between Raid_0 and Raid_1?
Steve: In Raid_0 the zero stands for how many files you are going to get back if something goes wrong.

(http://bash.org/?854608)

[@PingWin]

Вы, таки, сильно путаете Raid0 и Raid1. У raid1 инфа на дисках идентична, за исключением самого raid-заголовка. В Raid0, Raid5, 6 и т.д. инфа размазана по дискам.

[@merlin-vrn]

Я больше не буду! Честно-честно.

[@flaresun]

>Не знаю, как устроен NVidia fake-RAID 0, но Linux Software RAID0 устроен так: каждый
> из дисков можно использовать сам по себе, «без RAID», поскольку они идентичны.

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

[@flaresun]

Да, я прочитал комментарий и ответил на него. Да, я не видел, что тут уже два подобных коммента. Ну ничего с этим не поделаешь… :)

[@fzfx]

так точно. =) но у меня не получилось — радиус кривизны рук слишком мал. пришлось выдумывать.

[@tozx]

Фил, ты дважды молодец — написал таки статью, ну и восстановил данные!
молодцом!
хорошее начало.
скрипт с заботливыми комментариями

if ($timert1 == 16192) { # останавливаем время от времени операцию, давая дискам остыть
$timert1 = 0;
print («So hot! Sleeping for 33 sec...\n»);

тож порадовал.

надеюсь, парсер не лох )

[@fzfx]

напрягает комментирование после '{'? =)

[@tozx]

хех. нет. все вполне аккуратно. даже на тебя не похоже =))

[@Peretyaka]

Я думаю, радует то, что где-то таймаута может и не быть и диски поджарятся. Ну это про таких горе-программистов как я, которым проще попробовать, чем еще раз подумать, я надеюсь, автор не такой :)

[@ipod]

Слова «ложить» нету, а «положить» есть.
А за статью спасибо, будем надается не пригодится)

[@dfayruzov]

Отличная статья, спасибо!

Сам поволновался на этих выходных, когда свежесобранный Raid5 массив со всеми слитыми на него данными, отформатированный в ext4, развопился при очередной перезагрузке.
Но mkfs с правильными параметрами меня спасла. )

Я правильно понимаю, что размер страйпа это параметр chunk size, с которым запускаеся mdadm --create?

[@dfayruzov]

> Но mkfs с правильными параметрами меня спасла. )

e2fsck, конечно же. )

[@zhnikita]

Автор — Монстр!
За статью — спасибо! Но надеюсь, что никогда не пригодиться… :-)

[@surabujin]

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

[@fzfx]

собственно, согласен.
этой же логике я и следовал: какие изменения будет вносить mdadm, пока я буду пытаться подобрать правильные команды, я не знаю. а вот что делает dd — это мне вполне понятно. в случае с mdadm я бы не решился ничего делать, пока заранее не снял бы посекторные резервные копии с обоих винтов тем же dd.

[@Sp1ke]

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

[@Goodkat]

ты ханжа

[@fzfx]

считайте меня мазальщиком, но я ничего не крал.

[@tozx]

фактический украденный? при наличии 10ка штук такой же модели?
гм. вы ханжа.
если бы клиенту понадобился этот винчестер — Фил бы его отдал без разговоров. и получил бы любой другой подходящий.

[@Goodkat]

бэкапить, бэкапить и ещё раз бэкапить

[@qmax]

труъ хакеръ!
респект :)

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

[@iZENfire]

Размер одного диска в секторах можно узнать с помощью Victoria, либо посмотрев на наклейку на диске (LBA).

Разве линуксовый fdisk не может показать размеры партиций в секторах и для этого нужно лезть в Windows или вынимать диски из стойки? O_o

[@fzfx]

может и умеет, сиё мне неизвестно. =)

[@new_rock]

«RAID 0 из двух Samsung'ов» какраз идеальная тема для раздела «Я безумный». У кого много винтов самсунга, тот поймет :)

[@fzfx]

у меня много винтов самсунга. =) 4 штуки. намёк ваш понятен, да вот беда: самсунги мои работают нормально и уже давно. более того, на работе через наш бракотдел сильно чаще, нежели самсунговские, проходят винты другого производителя, тоже на букву «с». особенно часто — в последние месяцы, кто работает в сервисе — тот поймёт.

[@new_rock]

4 это мало.

[@fzfx]

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

[@strk]

сильно нервничали пока копировали? Ведь, как я понимаю, одна ошибка в рассчётах и начинать всё сначала)

[@fzfx]

нервничал не сильно. =) единственное, что я мог потерять — это время. при восстановлении не использовались никакие команды, которые могли бы затереть данные на дисках из бывшего рейда. ну, вернее, 'dd' могла затереть, если бы я попутал местами 'if' и 'of', так что просто был предельно внимателен. а если ошибся где-то в рассчётах — то таки да, пришлось бы править скрипт, снова пытаться определить размер страйпа и терять ещё 1 день на копирование.

[@Vayun]

В статье отсутсвует самое главное — вывод о том, что все эти тн «чипсетные» рейды понижают устойчивость к сбоям, а не повышают (как должно бы было). Если жалко денег на приличный контроллер, лучше RAID средствами операционки (чисто софтовый). Даже на «поиграться» большинство чипсетных поделок не тянет.

[@fzfx]

должен заметить. не спорю, fake raid драйверозависим и негибок. однако, исходя из своего печального опыта, хочу заметить: в первую очередь надёжность raid понижает невнимательное и халатное к нему отношение, начиная со стадии выбора комплектующих для raid (я приобрёл говномобайлреки, которые работали с костылями, и, как оказалось впоследствии, херово) и заканчивая его поддержкой (я отключил бипер рейда — бухгалтеру мешал — и забыл его включить по окончании работ). полностью аппаратный рейд — тоже вещь капризная и требовательная к грамотной его реализации. меня спасла утилита проверки файловой системы reiserfs, однако пока я до неё добрался — через дебри LVM и LUKS — по всем правилам восстановления данных (посекторное снятие раздела reiserfs размером 890 ГБ, лежащего внутри LVM, лежащего внутри LUKS), я осознал правильность нескольких устверждений:
1. бэкапы.
2. всё в первую очередь для рейда, во вторую — для бухов / директоров / прочих недовольних.
3. то, что меня спасла утилита проверки reiserfs, не обязательно повторится в следующий раз, если я буду пренебрегать пунктами 1-2.