LINUX.ORG.RU
ФорумAdmin

mdadm сгорел диск, raid 10

 , ,


0

2

Доброго времени суток.

Был софтверный рейд, построенный с помощью mdadm.

По нелепому стечению обстоятельств сгорел один из дисков, и утащил за собой ещё два диска, т.е. они работают, но raid их не видит. И ни каким образом не удается воткнуть в массив новый диск.

Вывод sudo mdadm -D /dev/md10:

/dev/md10:
        Version : 1.2
  Creation Time : Tue Jul  3 22:27:28 2012
     Raid Level : raid10
  Used Dev Size : 976758784 (931.51 GiB 1000.20 GB)
   Raid Devices : 4
  Total Devices : 1
    Persistence : Superblock is persistent

    Update Time : Sun Feb  1 00:57:08 2015
          State : active, FAILED, Not Started
 Active Devices : 1
Working Devices : 1
 Failed Devices : 0
  Spare Devices : 0

         Layout : near=2
     Chunk Size : 512K

           Name : kirgi:10  (local to host kirgi)
           UUID : 02dae489:3687e684:321b6bfa:e75e9737
         Events : 101582

    Number   Major   Minor   RaidDevice State
       0       8       17        0      active sync   /dev/sdb1
       1       0        0        1      removed
       2       0        0        2      removed
       3       0        0        3      removed

Как заново всё активировать?


они работают, но raid их не видит

как ты это определил? может не работают поэтому и не видит.

ни каким образом не удается воткнуть в массив новый диск.

что и куда ты собрался фтыкать? у тебя от массива четверть жива осталась. сначала разберись с теми двумя «работающими» дисками. потом когда увидишь их в выводе, тогда добавишь недостающий. или ты хочешь купить новый диск, добавить его в мертвый RAID а потом узнать, что те два диска тоже умерли? это такое ССЗБ, что даже суровый mdadm от него фулпруфит...

anonymous
()

Закономерность

Вот почему нет тем о восстановлении программного RAID на ZFS или GEOM Mirror?

Как только случается сбой в работе программного RAID на Linux, то тут целая история разворачивается. И, как правило, с несчастливым концом.

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

вывод fdisk -l:

Disk /dev/sda: 120.0 GB, 120034123776 bytes
255 heads, 63 sectors/track, 14593 cylinders
Units = cylinders of 16065 * 512 = 8225280 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disk identifier: 0x00093d15

   Device Boot      Start         End      Blocks   Id  System
/dev/sda1               1        7295    58592256   83  Linux
/dev/sda2            7295       14594    58626049    5  Extended
/dev/sda5            7295        8511     9764864   83  Linux
/dev/sda6            8511        9727     9764864   83  Linux
/dev/sda7            9727       10942     9764864   82  Linux swap / Solaris
/dev/sda8           10943       12158     9764864   83  Linux
/dev/sda9           12158       14594    19562496   83  Linux

Disk /dev/sdb: 1000.2 GB, 1000204886016 bytes
255 heads, 63 sectors/track, 121601 cylinders
Units = cylinders of 16065 * 512 = 8225280 bytes
Sector size (logical/physical): 512 bytes / 4096 bytes
I/O size (minimum/optimal): 4096 bytes / 4096 bytes
Disk identifier: 0x99b03185

   Device Boot      Start         End      Blocks   Id  System
/dev/sdb1               1      121601   976760001   fd  Linux raid autodetect
Partition 1 does not start on physical sector boundary.

Disk /dev/sdc: 1000.2 GB, 1000204886016 bytes
255 heads, 63 sectors/track, 121601 cylinders
Units = cylinders of 16065 * 512 = 8225280 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disk identifier: 0x39efb996

   Device Boot      Start         End      Blocks   Id  System
/dev/sdc1               1      121601   976760001    5  Extended

Disk /dev/sdd: 1000.2 GB, 1000204886016 bytes
255 heads, 63 sectors/track, 121601 cylinders
Units = cylinders of 16065 * 512 = 8225280 bytes
Sector size (logical/physical): 512 bytes / 4096 bytes
I/O size (minimum/optimal): 4096 bytes / 4096 bytes
Disk identifier: 0x37c506e0

   Device Boot      Start         End      Blocks   Id  System
/dev/sdd1               1      121601   976760001   83  Linux
Partition 1 does not start on physical sector boundary.

Disk /dev/sde: 1000.2 GB, 1000204886016 bytes
255 heads, 63 sectors/track, 121601 cylinders
Units = cylinders of 16065 * 512 = 8225280 bytes
Sector size (logical/physical): 512 bytes / 4096 bytes
I/O size (minimum/optimal): 4096 bytes / 4096 bytes
Disk identifier: 0x74f1121d

   Device Boot      Start         End      Blocks   Id  System
/dev/sde1               1      121601   976760001   83  Linux
Partition 1 does not start on physical sector boundary.

Поэтому я считаю что диски живые. sdc новый диск.

Sdis
() автор топика

Засунь все это в другую тачку для начала, возможно подохли порты, и прогнать smart также не помешает

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

К сожалению в другую машину харды переставить не могу. Но могу показать следующие:

1-ый

mdadm -E /dev/sdb1
/dev/sdb1:
          Magic : a92b4efc
        Version : 1.2
    Feature Map : 0x0
     Array UUID : 02dae489:3687e684:321b6bfa:e75e9737
           Name : kirgi:10  (local to host kirgi)
  Creation Time : Tue Jul  3 22:27:28 2012
     Raid Level : raid10
   Raid Devices : 4

 Avail Dev Size : 1953517954 (931.51 GiB 1000.20 GB)
     Array Size : 3907035136 (1863.02 GiB 2000.40 GB)
  Used Dev Size : 1953517568 (931.51 GiB 1000.20 GB)
    Data Offset : 2048 sectors
   Super Offset : 8 sectors
          State : clean
    Device UUID : b9cf8448:3f320a03:360ffa41:55043b8b

    Update Time : Sun Feb  1 00:57:08 2015
       Checksum : 28009bc7 - correct
         Events : 101582

         Layout : near=2
     Chunk Size : 512K

   Device Role : Active device 0
   Array State : A... ('A' == active, '.' == missing)
2-ой
mdadm -E /dev/sdc1
mdadm: No md superblock detected on /dev/sdc1..
3-ий
mdadm -E /dev/sdd1
/dev/sdd1:
          Magic : a92b4efc
        Version : 1.2
    Feature Map : 0x0
     Array UUID : 02dae489:3687e684:321b6bfa:e75e9737
           Name : kirgi:10  (local to host kirgi)
  Creation Time : Tue Jul  3 22:27:28 2012
     Raid Level : raid10
   Raid Devices : 4

 Avail Dev Size : 1953517954 (931.51 GiB 1000.20 GB)
     Array Size : 3907035136 (1863.02 GiB 2000.40 GB)
  Used Dev Size : 1953517568 (931.51 GiB 1000.20 GB)
    Data Offset : 2048 sectors
   Super Offset : 8 sectors
          State : clean
    Device UUID : 81b89978:550e18e9:a4538e44:3294a500

    Update Time : Sun Feb  1 00:57:08 2015
       Checksum : b620a826 - correct
         Events : 0

         Layout : near=2
     Chunk Size : 512K

   Device Role : spare
   Array State : A... ('A' == active, '.' == missing)
4-ый
mdadm -E /dev/sde1
/dev/sde1:
          Magic : a92b4efc
        Version : 1.2
    Feature Map : 0x0
     Array UUID : 02dae489:3687e684:321b6bfa:e75e9737
           Name : kirgi:10  (local to host kirgi)
  Creation Time : Tue Jul  3 22:27:28 2012
     Raid Level : raid10
   Raid Devices : 4

 Avail Dev Size : 1953517954 (931.51 GiB 1000.20 GB)
     Array Size : 3907035136 (1863.02 GiB 2000.40 GB)
  Used Dev Size : 1953517568 (931.51 GiB 1000.20 GB)
    Data Offset : 2048 sectors
   Super Offset : 8 sectors
          State : clean
    Device UUID : fd4b9340:3c34c305:8b328b79:7769d5f0

    Update Time : Sun Feb  1 00:57:08 2015
       Checksum : bff215b5 - correct
         Events : 0

         Layout : near=2
     Chunk Size : 512K

   Device Role : spare
   Array State : A... ('A' == active, '.' == missing)

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

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

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

Действительно торопится.

Но насколько проще пользовательский интерфейс у ZFS. От этих простыней вывода mdadm в глазах рябит :)

anonymous
()
Ответ на: Закономерность от iZEN

почему нет тем о восстановлении программного RAID на ZFS

так это крещеных еще мало, да и от железопроблем ZFS не спасет.

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

хотя сперва, возможно, надо подумать, почему те два диска помечены как 'spare'

не уверен.

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

да и zfs используют два с половиной лоровцы

Несмотря на то, что mdadm в линупсе доступен уже лет 15, используют его, похоже, примерно те же две с половиной лор-овцы (сорри, не удержался :)), за 15+ часов никаких конкретных инструкций по исправлению проблемы не поступило.

Пичалька...

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

Для конкретных инструкций слишком мало информации и слишком много вариантов того, что же могло пойти не так. К тому же, судя по «Device Role : spare», кто-то там уже покопался своими шаловливыми ручками и не сознаётся в содеянном.

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

Вообще, есть универсальный и довольно неплохой способ: пересоздать массив на тех же дисках в том же порядке с той же версией матаданных (1.2 в данном случае) и опцией --assume-clean. В этом случае mdadm перезапишет метаданные, но сами данные останутся на месте. Естественно, делать такое следует очень осторожно, предварительно сделав бэкапы.

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

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

В ZFS как-то попроще будет:

# mkfile -n 64m /var/tmp/m0
# mkfile -n 64m /var/tmp/m1
# mkfile -n 64m /var/tmp/m2
# mkfile -n 64m /var/tmp/m3
#
# zpool create m mirror /var/tmp/m[01] mirror /var/tmp/m[23]
#
# zpool list m
NAME  SIZE  ALLOC  FREE  CAP  DEDUP  HEALTH  ALTROOT
m     118M   178K  118M   0%  1.00x  ONLINE  -
#
# zfs list m
NAME   USED  AVAIL  REFER  MOUNTPOINT
m     95.5K  85.9M    31K  /m
#
# zpool status m
  pool: m
 state: ONLINE
  scan: none requested
config:

        NAME             STATE     READ WRITE CKSUM
        m                ONLINE       0     0     0
          mirror-0       ONLINE       0     0     0
            /var/tmp/m0  ONLINE       0     0     0
            /var/tmp/m1  ONLINE       0     0     0
          mirror-1       ONLINE       0     0     0
            /var/tmp/m2  ONLINE       0     0     0
            /var/tmp/m3  ONLINE       0     0     0

errors: No known data errors
#
# zpool export m
#
# gzip /var/tmp/m[123]

Сжав 3 устройства из четырех мы сделали вид, что их больше нет. Смотрим:

# zpool import -d /var/tmp/m0
  pool: m
    id: 14293252969743188547
 state: UNAVAIL
status: One or more devices are unavailable.
action: The pool cannot be imported due to unavailable devices or data.
config:

        m                UNAVAIL  corrupted data
          mirror-0       DEGRADED
            /var/tmp/m0  ONLINE
            /var/tmp/m1  UNAVAIL  cannot open

device details:

        /var/tmp/m1    UNAVAIL    cannot open
        status: ZFS detected errors on this device.
                The device was missing.

        missing-1      UNAVAIL    corrupted data
        status: ZFS detected errors on this device.
                The device has bad label or disk contents.

#

Сразу ясно, какого диска не хватает в mirror-0. Про mirror-1 непонятно ничего, но это явная недоработка - ибо копии полной конфигурации здесь имеются на всех дисках, так что все дело в том, чтобы ее оттуда достать и показать.

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

Ты давай поосторожнее с квантором всеобщности :)

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

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

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

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

Сначала надо бы попробовать assemble с ключом --force

У меня есть подозрение, что автор темы (или кто-то другой) уже пытался что-то сделать, и в результате удалил и передобавил два диска как spare. Теперь система не может собрать массив, так как справедливо считает, что остался всего один диск, а значит - восстановление невозможно в принципе.

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

Понятно только какая она сейчас (в момент написания команды), но от этого немного толку.

Ну конечно, простыня mdadm'а намного понятнее.

Запустив zdb под mdb и уговорив ее не ругаться на отстутствующие диски, получил следующее:

# mdb /usr/sbin/i86/zdb
> :r -e -p /var/tmp/m0 -Cs m

----====<<<< много уговоров пропущено >>>>====----

MOS Configuration:
        version: 28
        name: 'm'
        state: 1
        txg: 11
        pool_guid: 14293252969743188547
        timestamp: 1423118998
        hostid: 648501
        hostname: 'solaris'
        vdev_children: 2
        vdev_tree:
            type: 'root'
            id: 0
            guid: 14293252969743188547
            create_txg: 4
            children[0]:
                type: 'mirror'
                id: 0
                guid: 16571281281997042894
                metaslab_array: 28
                metaslab_shift: 20
                ashift: 9
                asize: 62390272
                is_log: 0
                create_txg: 4
                children[0]:
                    type: 'file'
                    id: 0
                    guid: 6960683704345289896
                    path: '/var/tmp/m0'
                    create_txg: 4
                children[1]:
                    type: 'file'
                    id: 1
                    guid: 2126868905361258211
                    path: '/var/tmp/m1'
                    create_txg: 4
            children[1]:
                type: 'mirror'
                id: 1
                guid: 18149826480952127793
                metaslab_array: 27
                metaslab_shift: 20
                ashift: 9
                asize: 62390272
                is_log: 0
                create_txg: 4
                children[0]:
                    type: 'file'
                    id: 0
                    guid: 5715080492827904731
                    path: '/var/tmp/m2'
                    create_txg: 4
                children[1]:
                    type: 'file'
                    id: 1
                    guid: 7878923788549121822
                    path: '/var/tmp/m3'
                    create_txg: 4
                            capacity   operations   bandwidth  ---- errors ----
description                used avail  read write  read write  read write cksum
m                         97.0K  118M     0     0    59     0     0     0     0
  mirror                  38.0K 59.0M     0     0    59     0     0     0     0
    /var/tmp/m0                           0     0 3.49K     0     0     0     0
    /var/tmp/m1                           0     0     0     0     0     0     0
  mirror                  59.0K 58.9M     0     0     0     0     0     0     0
    /var/tmp/m2                           0     0     0     0     0     0     0
    /var/tmp/m3                           0     0     0     0     0     0     0
mdb: target has terminated
>

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

Где те двое с половиной лоровец, которые то же самое из одного выжившего диска под управлением mdadm извлекут?

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

Какую предыдущую?

У нас было два зеркала в пуле, собранные из двух дисков. Три из 4 дисков пропали. Из оставшегося одного мы извлекли полную конфигурацию пула - такую, какая она должна быть.

Чего тебе не хватает?

Давай, показывай, как ты такое с mdadm проделаешь. А то разговоров тут про то, как ZFS никто не использует, все используют mdadm, а как до дела доходит - оказывается, что все немного не так.

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

У нас было два зеркала в пуле, собранные из двух дисков.

Откуда я могу знать, что у тебя пять минут назад там было два диска, а не пять, например? В контексте темы это очень важно. Диски не могут сначала ВНЕЗАПНО исчезнуть, а потом так же ВНЕЗАПНО стать spare. Это можно только руками сделать.

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

Давай, показывай, как ты такое с mdadm проделаешь.

Аха, afaik у них там метаданные по массиву рамазаны, а не на составляющих дисках, так что хрена лысого, а не конфу вытащить :)

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

Аха, afaik у них там метаданные по массиву рамазаны, а не на составляющих дисках, так что хрена лысого, а не конфу вытащить :)

Блин, где вас таких делают?

«У нас» метаданные точно так же раскопированы на все диски. Так что конфигурацию можно вытащить из одного диска. Только толку от этого не будет если эта конфигурация уже поломана руками.

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

каких конкретных данных не хватает? Свои руки держал при себе. Единственное что сделал это попытался добавить новый диск в рейд.

 mdadm --manage /dev/md10 --add /dev/sdc1                 
mdadm: add new device failed for /dev/sdc1 as 4: Invalid argument
Sdis
() автор топика
Ответ на: комментарий от EvgGad_303

Точно не там где вас. Что мешает вытащить и собрать как должно быть?

Вытащить что? Конфиг RAID10 с одним диском? Это очевидно неработоспособная конфигурация, она не работает, не будет работать, не должна работать и не могла работать в прошлом. Как должно быть? А я не знаю как должно быть, в RAID10 порядок дисков важен. Направление работы я уже подсказал: пересоздать массив с --assume-clean.

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

Точно никто не пытался добавить другие «выпавшие» диски? Точно до этого массив был полным, а не состоял из всего двух дисков?

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

 cat /proc/mdstat
Personalities : [raid10]
md10 : inactive sdb1[0]
      976758977 blocks super 1.2

unused devices: <none>
Sdis
() автор топика
Ответ на: комментарий от Deleted

Вообще можно просто сделать бэкап (dd на другой сторадж) всех дисков, затем в разном порядке дисков пересоздавать RAID10 с metadata 1.2 и assume clean, и затем смотреть что получилось и пытаться монтировать ФС в r/o. Если данные там действительно сохранились, то должно получиться.

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

Raid Devices : 4

Из ОП тебе ни о чём не говорит? И внизу поста

Number   Major   Minor   RaidDevice State
       0       8       17        0      active sync   /dev/sdb1
       1       0        0        1      removed
       2       0        0        2      removed
       3       0        0        3      removed
Т.е. mdadm знает про 4 диска.

Как должно быть? А я не знаю как должно быть

Вот и ваш mdadm не в курсе, видимо, ну, как обычно т.е.

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

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

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

Если тебе не нравится уничтожение сжатием, то можно на трех якобы умерших дисках и другой пул создать. Результат не изменится. Я даже готов тебе это продемонстрировать, но только после того, как ты начнешь хотя бы пытаться продемонстрировать что-то подобное с mdadm.

В контексте темы это очень важно. Диски не могут сначала ВНЕЗАПНО исчезнуть, а потом так же ВНЕЗАПНО стать spare. Это можно только руками сделать.

Ты, конечно же, как работает mdadm знаешь как отче наш, я правильно тебя понимаю? Или ты хочешь сказать, что в mdadm ошибок быть не может потому что их там не может быть никогда? Эта самая простая отмазка, с которой можно отъехать :)

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

Ну тогда смотри мой предыдущий комментарий.

mdadm --zero-superblock $ВЫЖИВШИЙ_ДИСК_1
mdadm --zero-superblock $ВЫЖИВШИЙ_ДИСК_2
mdadm --zero-superblock $ВЫЖИВШИЙ_ДИСК_3
mdadm --metadata=1.2 --create /dev/md$N --level=10 --raid-devices=4 $ВЫЖИВШИЙ_ДИСК_1 missing $ВЫЖИВШИЙ_ДИСК_2 $ВЫЖИВШИЙ_ДИСК_3
# Далее смотрим разделы/LVM если были, пробуем mount -o ro...
Перед этим - сделать бэкапы. Комбинации дисков и missing пробовать разные. Новый диск не трогать.

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

Какое «такое»?

Такое, mdadm показывает один и тот же гуид для всех трех дисков, про первый из трех он даже говорит, что диск Активен, он также даже знает про то, что дисков должно быть четыре... Неужели такая большая проблема выяснить, в каком зеркале были оставшиеся два диска?

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

Комбинации дисков и missing пробовать разные.

Ну что ж, метод научного тыка - тоже метод, в конце концов.

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

Ок, ты победил. ZFS - рулит, линукс - сосёт.

Заметь, про сосет это ты сам сказал, я этого не говорил.

Может там все дело в том, что у разделов типы неправильные и этот ваш mdadm в них даже не заглядывает или считает их неполноценными и пригодными для использования только как запаски? У единственного диска, про который он говорит Active - тип «Linux raid autodetect», у всех остальных что-то другое.

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

Может там все дело в том, что у разделов типы неправильные и этот ваш mdadm в них даже не заглядывает или считает их неполноценными и пригодными для использования только как запаски? У единственного диска, про который он говорит Active - тип «Linux raid autodetect», у всех остальных что-то другое.

Возможно дело в этом. Но давайте таки включим логику. У нас есть последовательность событий:

  • Раньше всё работало.
  • Сгорел один диск.
  • Не делалось ничего, кроме неудавшейся попытки добавить новый диск (sdc, на нём нет метаданных).
  • У нас RAID10 из одного диска.

Можно предположить, что проблема действительно в типах разделов. Но тогда почему всё работало до этого?

Кстати лично я не уверен насчёт типов разделов. ИМХО система просто ищет метаданные. Иначе бы это не работало без разделов.

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

Не делалось ничего, кроме неудавшейся попытки добавить новый диск (sdc, на нём нет метаданных).

Ну «оно само» это оно завсегда так.

Можно предположить, что проблема действительно в типах разделов. Но тогда почему всё работало до этого?

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

Кстати лично я не уверен насчёт типов разделов. ИМХО система просто ищет метаданные. Иначе бы это не работало без разделов.

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

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

Фи, как неспортивно. А вроде так бодро подхватил эстафету :)

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

ок.

Ща поставил всё бекапиться.

Как это произойдет отпишусь что получилось.

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