LINUX.ORG.RU
ФорумAdmin

mdadm raid10 как восстановить?

 ,


1

2

Привет всем.

Есть массив mdadm raid10. Развалился. попытки запуска безуспешны.

Вот что есть: detail


/dev/md0:
           Version : 1.0
     Creation Time : Sun Sep 10 09:38:18 2023
        Raid Level : raid10
     Used Dev Size : 234429888 (223.57 GiB 240.06 GB)
      Raid Devices : 4
     Total Devices : 2
       Persistence : Superblock is persistent

       Update Time : Sun Dec 28 14:32:44 2025
             State : active, FAILED, Not Started 
    Active Devices : 2
   Working Devices : 2
    Failed Devices : 0
     Spare Devices : 0

            Layout : near=2
        Chunk Size : 64K

Consistency Policy : unknown

              Name : any:0
              UUID : b7175757:a15ed574:6940d0a2:589e6c79
            Events : 9090299

    Number   Major   Minor   RaidDevice State
       -       0        0        0      removed
       -       0        0        1      removed
       -       0        0        2      removed
       -       0        0        3      removed

       -       8       49        2      sync set-A   /dev/sdd1
       -       8       65        3      sync set-B   /dev/sde1

И вот examine


/dev/sdb1:
          Magic : a92b4efc
        Version : 1.0
    Feature Map : 0x1
     Array UUID : b7175757:a15ed574:6940d0a2:589e6c79
           Name : any:0
  Creation Time : Sun Sep 10 09:38:18 2023
     Raid Level : raid10
   Raid Devices : 4

 Avail Dev Size : 468860048 sectors (223.57 GiB 240.06 GB)
     Array Size : 468859776 KiB (447.14 GiB 480.11 GB)
  Used Dev Size : 468859776 sectors (223.57 GiB 240.06 GB)
   Super Offset : 468860064 sectors
   Unused Space : before=0 sectors, after=272 sectors
          State : active
    Device UUID : c0cde6fe:dc6927c6:8f8cda7c:2bebda0e

Internal Bitmap : -16 sectors from superblock
    Update Time : Sun Dec 28 14:31:11 2025
  Bad Block Log : 512 entries available at offset -8 sectors
       Checksum : 3f8ea6a9 - correct
         Events : 9090209

         Layout : near=2
     Chunk Size : 64K

   Device Role : Active device 1
   Array State : .AAA ('A' == active, '.' == missing, 'R' == replacing)
/dev/sdc1:
          Magic : a92b4efc
        Version : 1.0
    Feature Map : 0x1
     Array UUID : b7175757:a15ed574:6940d0a2:589e6c79
           Name : any:0
  Creation Time : Sun Sep 10 09:38:18 2023
     Raid Level : raid10
   Raid Devices : 4

 Avail Dev Size : 468860048 sectors (223.57 GiB 240.06 GB)
     Array Size : 468859776 KiB (447.14 GiB 480.11 GB)
  Used Dev Size : 468859776 sectors (223.57 GiB 240.06 GB)
   Super Offset : 468860064 sectors
   Unused Space : before=0 sectors, after=272 sectors
          State : active
    Device UUID : e000d80f:a184c947:65fe1179:bda5b5ae

Internal Bitmap : -16 sectors from superblock
    Update Time : Fri Nov  7 02:52:14 2025
  Bad Block Log : 512 entries available at offset -8 sectors
       Checksum : 6dc58c1e - correct
         Events : 6357014

         Layout : near=2
     Chunk Size : 64K

   Device Role : Active device 0
   Array State : AAAA ('A' == active, '.' == missing, 'R' == replacing)
/dev/sdd1:
          Magic : a92b4efc
        Version : 1.0
    Feature Map : 0x1
     Array UUID : b7175757:a15ed574:6940d0a2:589e6c79
           Name : any:0
  Creation Time : Sun Sep 10 09:38:18 2023
     Raid Level : raid10
   Raid Devices : 4

 Avail Dev Size : 468860048 sectors (223.57 GiB 240.06 GB)
     Array Size : 468859776 KiB (447.14 GiB 480.11 GB)
  Used Dev Size : 468859776 sectors (223.57 GiB 240.06 GB)
   Super Offset : 468860064 sectors
   Unused Space : before=0 sectors, after=272 sectors
          State : clean
    Device UUID : 2e978f51:fccb8e12:523fa647:7b1d0b47

Internal Bitmap : -16 sectors from superblock
    Update Time : Sun Dec 28 14:32:44 2025
  Bad Block Log : 512 entries available at offset -8 sectors
       Checksum : e19ab800 - correct
         Events : 9090299

         Layout : near=2
     Chunk Size : 64K

   Device Role : Active device 2
   Array State : .AAA ('A' == active, '.' == missing, 'R' == replacing)
/dev/sde1:
          Magic : a92b4efc
        Version : 1.0
    Feature Map : 0x1
     Array UUID : b7175757:a15ed574:6940d0a2:589e6c79
           Name : any:0
  Creation Time : Sun Sep 10 09:38:18 2023
     Raid Level : raid10
   Raid Devices : 4

 Avail Dev Size : 468860048 sectors (223.57 GiB 240.06 GB)
     Array Size : 468859776 KiB (447.14 GiB 480.11 GB)
  Used Dev Size : 468859776 sectors (223.57 GiB 240.06 GB)
   Super Offset : 468860064 sectors
   Unused Space : before=0 sectors, after=272 sectors
          State : clean
    Device UUID : 210b29de:319063a4:6ffff831:68ced113

Internal Bitmap : -16 sectors from superblock
    Update Time : Sun Dec 28 14:32:44 2025
  Bad Block Log : 512 entries available at offset -8 sectors
       Checksum : b7226134 - correct
         Events : 9090299

         Layout : near=2
     Chunk Size : 64K

   Device Role : Active device 3
   Array State : .AAA ('A' == active, '.' == missing, 'R' == replacing)

Прошу знатоков помочь в восстановлении. Спасибо.

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

Я задал вам вопрос «На прям любые мобильные девайсы поставите?», но вы ушли от ответа до уровня «Лично я поставлю на ноутбук. Другое имеющееся мобильное устройство для интернета не используется».

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

Ну, ИБМ как-то выпустил партию дятлов, которые тоже пачками сыпались. А в грядущем, возможно, выпустят партию НЖМД с гелием и некачественным уплотнителем, который через год рассыпается. И получится, что в raid'е диски сдохли и запасные в сейфе тоже.

там хотя бы будет заметно

Нет, если у НЖМД умирает служебка, то он стабильно работает до первого ребута. А кто компы с raid'ом часто ребутит? Два года работало, а там при ребуте не один НЖМД отвалился и всё.

Конечно, может, правильная прошивка при self test проверяет состояние служебных областей, ну дак напишут неправильную. Вон, SSD для постоянно выпускают кривые прошивки, скоро и до SATA и до SAS НЖМД доберутся :)

только на HDD делать

Это смотря какого результата хочется достичь. Если считать, что raid не отменяет резервные копии...

mky ★★★★★
()

dd всех дисков и пробовать собирать массив в виртуальной машине.

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

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

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

Нет, если у НЖМД умирает служебка, то он стабильно работает до первого ребута

Это же вредительство какое-то, неужели все производители так делают?

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

Да всё в этом мире вредительство :)

Если служебку не удаётся прочитать, то как работать? Раньше её многократно дублировали, допустим, какой-то древний Maxtor хранил 10 копий, на разных фиксированых цилидрах. Что там в современных не знаю, но сейчас ведь кроме блинов, прошивка может что-то во флеше сохранять. И этот флеш тоже может внезапно обнулится.

Берданы, у которых по SMART было всё хорошо, а после перезагрузки труп, встречал 3-4 раза. В целом, я согласен, что НЖМД надёжнее SSD, но, шумные и тормозные.

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

Если служебку не удаётся прочитать, то как работать?

А каким образом служебка нужна для поднятия sata-интерфейса? Даже если в ней были данные, без которых нельзя транслировать линейные адреса в физические (аналог CHS), то можно например предоставить хосту возможность настроить всё заново перед тем как команды обычного I/O зааработают.

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

Для настройки НЖМД очень продолжительное время существовал UART на отдельном разъёме. Может и на современных остался. Только производитель даёт ноль информации какая прошивка какие команды через UART понимает. Ему так проще. Зачем ему заморачиваться? У него нет задачи создать самый живучий НЖМД, с которого всегда можно что-то вытащить. Он производит приемлемый рынком продукт. А так нужно будет или документацию открывать/разжёвывать или вобще разрабатывать специальный софт по восстановлению...

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

Вопрос звучал так: «На прям любые мобильные девайсы поставите?» Вы же сократили ваше «Я писал выше что никто не мешает поставить это на несколько своих устройств, да и хоть на все.» до «Лично я поставлю на ноутбук.» т.е. ваше «все» сократилось до одного ноута.

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

В целом, я согласен, что НЖМД надёжнее SSD, но, шумные

Ну если это не 10-15k rpm то шум от них только в моменты работы блока головок.

и тормозные.

Тут зависит от того «куда вы торопитесь», т.е. насколько активно i/o в вашем случае использования. В каких-то случаях да, ssd очень даже годно, а в каких-то в целом побарабану до этой скорости.

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

Дошли руки, решил проверить текущий уровень записи: все диски 5,4 Tb получается за два года работы. Диски выбирались из расчета на неинтенсивную работу. Там работает два человека от силы. Да, это не тру-серверные железки, на что дали денег, то и берем.

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

на sdb - с 1 половины, sdd или sde. скорее всего sde. а вторая половинка так и осталась ждать замены.

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

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

С чего это? Чтобы прочитать служебку контроллер уже должен работать. Крайне сомневаюсь, что он уже научился обращаться к собственно хранилищу, но вот драйвер sata-интерфейса у него в служебке записан и его надо оттуда сначала прочитать.

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

4ый ssd то заменил? который sdc?

возьми любой который проходит по размеру посекторно

я бы вообще половинки разные сделал, заменил бы sdb и sdc на другие, а те - в ЗИП

mdadm -f жертва, mdadm -r жертва, меняешь

потом sfdisk -d /dev/другой-диск|sfdisk /dev/новый (бывшая жертва)

или для GPT sgdisk -R=/dev/новый /dev/другой-диск

и если GPT, то нужно ещё sgdisk -G /dev/новый

потом mdadm -a жертва (бывшая)

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

На sdb ничего не могло синхронизироваться, его вторая половина sdc вылетела ещё давно.

кстати, бонифацио - сейчас часто у разных SSD совпадает размер побайтный

Это всегда так было, и не только у ssd. Раньше исключения встречались чуть чаще чем сейчас.

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

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

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

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

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

нет. именно так: sdb-sde, sdc-sdd.

и про размер - ты не прав! имел опыт, 240ГБ Микрон и WD на замену - хорошо, что у WD секторов было больше! также нам покупали в ЗИП тошу (kioxia) вместо расово православного OEM Huawei. так вот. размер тоши был меньше нужного.:(

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

бывает! я кабелей уже много выкинул, включая переходники molex->15pin

плюс несовместимость. было несколько раз и конкретные SATA НЖМД и ТТД не хотели в определённых портах работать.

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

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

Или не поставят по причине xyz. Или поставят, но робить будет через пень колоду. Поймите правильно, я топлю только за ваше "... на несколько своих устройств, да и хоть на все."

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

Посмотри внимательный лог, там очевидно что у sdb второй половины не было. Собственно, если б она была, массив бы не развалился и автор дальше бы ничего не замечая работал бы с обычным raid0 вместо raid10.

и про размер - ты не прав! имел опыт, 240ГБ Микрон и WD на замену

Это когда было, 10 лет назад? И диски каких категорий? Если один из них сугубо домашний, второй энтерпрайзный то вероятность разницы выше.

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

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

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

я сразу посмотрел. кроме того у меня опыт есть. половинок нет в обоих наборах, A и B, а sdb1 - это rd 1,sdc1 - rd 0, sdd1 - rd 2, sde1 - rd 3, Layout : near=2:
- 0 0 0 removed
- 0 0 1 removed
- 0 0 2 removed
- 0 0 3 removed

   -       8       49        2      sync set-A   /dev/sdd1  
   -       8       65        3      sync set-B   /dev/sde1

=> sdb1+sde1 - stripe set-B, а sdc1+sdd1 - stripe set-A.
set-B - это зеркало set-A, т.е. его минимально достаточно для запуска, вставив обратно sdb - вернули к жизни md0, но без set-A.

с ТТД эта история была 2 года назад, отличались в размере несущественно. да, WD был «бытовой». но у любых бывают нестыковки, про Kioxia уже написал. или вот бытовые:
Capacity: 512 110 190 592 bytes [512 GB]
Capacity: 1 000 204 886 016 bytes [1,00 TB]
Capacity: 1 024 209 543 168 [1,02 TB]

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

set-B - это зеркало set-A, т.е. его минимально достаточно для запуска, вставив обратно sdb - вернули к жизни md0, но без set-A.

Ну примерно так, да. Только почему в этой ситуации ты считаешь что sdb мог куда-то синхронизироваться я не понимаю. Сам же видишь что sdc, его зеркала, нету.

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

bitmap свой он должен был синхронизовать, rdev4each - это он по всем составляющим md пробегает:

/*

  • bitmap file handling - read and write the bitmap file and its superblock
    */

    static int read_sb_page(struct mddev *mddev, loff_t offset,
    struct page *page, unsigned long index, int size)
    {

     sector_t sector = mddev->bitmap_info.offset + offset +  
             index * (PAGE_SIZE / SECTOR_SIZE);  
     struct md_rdev *rdev;  
    
     rdev_for_each(rdev, mddev) {  
    


относящиеся к делу h файлы:
#define rdev_for_each(rdev, mddev) \
list_for_each_entry(rdev, &((mddev)->disks), same_set)

#define list_for_each_entry(pos, head, member) \
for (pos = list_first_entry(head, typeof(*pos), member); \
!list_entry_is_head(pos, head, member); \
pos = list_next_entry(pos, member))

mumpster ★★★★★
()
Для того чтобы оставить комментарий войдите или зарегистрируйтесь.