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

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

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

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

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

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

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

вывод 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 новый диск.

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

То есть, если в 10 рeйде из 4 дисков на zfs останется один striped или mirrored - он будет работать как ни в чем не бывало?

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

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

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)

mdadm -E /dev/sdc1
mdadm: No md superblock detected on /dev/sdc1..

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)

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)

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

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

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

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

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

ну так собирай массив. из трёх хотя бы.

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

не уверен.

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

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

Пичалька...

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

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

https://raid.wiki.kernel.org/index.php/RAID_Recovery
Сначала надо бы попробовать assemble с ключом --force
Если данные критичны - все эксперименты по восстановлению надо производить с образами дисков

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

Может потому что ими никто не пользуется

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

В 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 непонятно ничего, но это явная недоработка - ибо копии полной конфигурации здесь имеются на всех дисках, так что все дело в том, чтобы ее оттуда достать и показать.

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

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

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

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

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

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

Ну конечно, простыня 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 извлекут?

И вот опять. Ты показываешь нам _текущую_ конфигурацию. Как увидеть предыдущую?

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

 mdadm --manage /dev/md10 --add /dev/sdc1                 
mdadm: add new device failed for /dev/sdc1 as 4: Invalid argument

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

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

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

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

Совершенно точно.

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 не в курсе, видимо, ну, как обычно т.е.

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

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

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

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

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

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

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...

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

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

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

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

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

Ты тоже победил. Поздравляю!

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

ок.

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

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

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

+1