LINUX.ORG.RU
ФорумAdmin

mdadm - странности с диском


0

3

Итак, огреб непонятно откуда грабли: то ли с переносом / на lvm поверх рэйда, то ли из-за initrd созданного dracut, то ли еще почему - регулярно /dev/sdc1 после ребута отказывается добавляться в рэйд-массив, светя невесть откуда взявшимся старым суперблоком. mdadm --zero-superblock не помогает.

Вчера плюнул сделал dd if=/dev/zero of=/dev/sdc1 bs=1M, потом - добавил диск в массив, итог после ребилда - все тот же:

# mdadm -E /dev/sdc1
/dev/sdc1:
          Magic : a92b4efc
        Version : 0.90.00
           UUID : c4eb1c03:da16a8f3:61cb7cfc:0422fd85 (local to host NiTr0)
  Creation Time : Sun Jun 13 23:53:14 2010
     Raid Level : raid5
  Used Dev Size : 976762432 (931.51 GiB 1000.20 GB)
     Array Size : 2930287296 (2794.54 GiB 3000.61 GB)
   Raid Devices : 4
  Total Devices : 4
Preferred Minor : 0

    Update Time : Wed Nov 30 20:18:48 2011
          State : active
 Active Devices : 4
Working Devices : 4
 Failed Devices : 0
  Spare Devices : 0
       Checksum : 8351ebae - expected 8351ebbe
         Events : 1141946

         Layout : left-symmetric
     Chunk Size : 64K

      Number   Major   Minor   RaidDevice State
this     2       8       33        2      active sync   /dev/sdc1

   0     0       8       33        0      active sync   /dev/sdc1
   1     1       8       49        1      active sync   /dev/sdd1
   2     2       8       17        2      active sync   /dev/sdb1
   3     3       8       65        3      active sync   /dev/sde1

Попутно - не заметил когда, но вроде давненько, после частичного краша массива (когда molex->2xsata отошел) массив сменился с md0 на md127.

Собссно вопрос - что это, и откуда оно вылезает?

Пока других идей, кроме как пересоздать массив (слив куда-то 3ТБ данных), либо собрать новый массив из 3х2ТБ дисков, продав освободившиеся 1ТБ, нет...

★★★★★

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

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

В mdadm.conf ни minor, ни тем более дата последнего доступа к дискам не прописана...

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

Какой такой недорейд? Нету оного, отключен, винты вообще висят на LSI 3041E (брал ради NCQ, MCP55 оный не поддерживает).

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

Завтра ребутнусь с лайв флэш, попробую глянуть.

NiTr0 ★★★★★
() автор топика

массив сменился с md0 на md127

массив должен быть прописан в /etc/mdadm.conf по UUID, тогда название блокдевайса слетать не должно

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

Ну я вообще нигде ничего не прописываю, autodetect рулит :)

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

Проблема не в названии блокдевайса. А в том, что после ребута волшебным образом вызалит старый суперблок с датой модификации 2011 год...

NiTr0 ★★★★★
() автор топика
Последнее исправление: NiTr0 (всего исправлений: 1)
Ответ на: комментарий от NiTr0

Останови все ( и mdadm, и dmraid ) лишние рейды, в которые по какому-то недоразумению вошёл этот диск

После этого обнули диск ( достаточно первый и последний гигабайт, этого хватит с запасом )

Если после перезагрузки что-то вылезло, проверь init скрипты ( и rc.local ), или всё же виноват железный (недо)рейд

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

Делал уже. Вылазило.

После проверки методом исключения, похоже, был выявлен источник - initrd, созданный dracut. Он менял super-minor на 3 дисках на 127, и гадил дату 4-го. Во всяком случае, без него все вроде хорошо. Пока что выкинул его нафиг.

Наверное, таки куплю под корень, /usr и /boot какой-то SSD гигов на 30 (или вообще поставлю какой-то винт из хламовника - пока не определился, но больше склоняюсь к ssd), настрою его бекапы на рэйд и на этом успокоюсь...

NiTr0 ★★★★★
() автор топика
Последнее исправление: NiTr0 (всего исправлений: 1)
Ответ на: комментарий от NiTr0

Чорт, вот я подозревал initrd, но подумал что это глупость...

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

Ради интереса: а зачем этот dracut нужен, при наличии вполне нормально работающих initramfs-tools, поставляемых с дистрибутивом?

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

gentoolkit? Как-то хотелось что-то попроще, а не комбайн из конфигуратора ядра с опцией создания рамдиска. Огреб граблей в итоге.

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

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

спроси мегабакса, может он подскажет лечится ли это

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

Сам не пробовал, но судя по тому, что тут https://www.jerryweb.org/settings/raid/ пишут, в Debian проблем нет. Хотя вообще идея в этом dracut здравая - сейчас в каждом дистрибутиве свой костыль - лишняя работа и баги.

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

Кстати, оффтопик, не холивара ради, просто интересно - а как оно держать генту в продакшене?

Если в дебиане я могу спокойно сделать apt-get update && apt-get dist-upgrade и быть уверенным, что всё останется работоспособным, то Gentoo ведь bleeding edge - после emerge --update world сквид/апач/... новой версии не сожрёт конфиг от старой, новое ядро откажется работать с кривым проприетарным модулем хитрой железки, новая версия subversion подавится хуками в репозитории для старой и т. п.? Или я не прав и оно как-то разруливается?

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

selivan

Кстати, оффтопик, не холивара ради, просто интересно - а как оно держать генту в продакшене?

Если в дебиане я могу спокойно сделать apt-get update && apt-get dist-upgrade и быть уверенным, что всё останется работоспособным, то Gentoo ведь bleeding edge - после emerge --update world сквид/апач/... новой версии не сожрёт конфиг от старой, новое ядро откажется работать с кривым проприетарным модулем хитрой железки, новая версия subversion подавится хуками в репозитории для старой и т. п.? Или я не прав и оно как-то разруливается?


В рамках stable-ветки всё будет хорошо в большинстве случаев.
Конфиги не подменяются. Там используются удобные инструменты (см. etc-update).

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

Посмотрел. «etc-update не сохраняет старые версии ваших конфигурационных файлов». Страшно, нах.

И всё-таки, например - в 2010 году squid 2.7 перестал поддерживаться, ему на смену пришёл 3.1(или 3.0? не помню). В Debian в рамках одного релиза будет висеть версия 2.7, с бек-портами патчей безопасности. 3.1 появится только в новом релизе. В Gentoo stable-ветка имеет какие-то версии, в рамках которой сквид всегда будет 2.7, или оно однажды всё-таки внезапно обновит 2.7 на 3.1 и он подавится конфигом?

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

Плохо держать в продакшне. На домашнем тазике (как сабжевый) - еще вполне ок, но там где простой критичен - я бы не советовал. Разве что 1-2 машины максимум. Профита мало, гимора много. Бинарные дистры - намного меньше внимания требуют к себе, обновления накатываются легко.

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

Не, держать можно, и случаев что из-за конфига рассыпется что-либо - на самом деле не так и много. Но по трудозатратам - времени на обслуживание уходит намного больше. В разы, если не на порядки.

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

Апдейт раз в год - снижает ессно затраты времени, но переростает в аццкую попоболь ввиду далеко ушедших вперед версий. Эдакий концентрат годичного аццкого гемора, выплеснутый мгновенно.

В общем, коротко - можно, но не нужно, бинарные дистры куда проще в обслуживании. Это если надо работать, а не разгребать последствия каждого апдейта. Для души - вполне можно иметь тазик...

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