Início / unix / Perguntas / 782219
Accepted
Marco
Asked: 2024-08-20 15:38:29 +0800 CST

"mdadm --grow" está preso em dispositivos defeituosos

  • 772

Não sou o primeiro com travamento mdadm --grow, mas acho que o meu é um pouco diferente dos outros. No meu caso, todos os dispositivos estão com defeito e o estado diz FAILED :

root@linux:~# mdadm --detail /dev/md126 
/dev/md126:
           Version : 1.2
     Creation Time : Tue Jan 26 11:57:52 2021
        Raid Level : raid5
        Array Size : 1953258496 (1862.77 GiB 2000.14 GB)
     Used Dev Size : 976629248 (931.39 GiB 1000.07 GB)
      Raid Devices : 4
     Total Devices : 4
       Persistence : Superblock is persistent

     Intent Bitmap : Internal

       Update Time : Mon Aug 19 14:56:31 2024
             State : active, FAILED, reshaping 
    Active Devices : 0
    Failed Devices : 4
     Spare Devices : 0

            Layout : left-symmetric
        Chunk Size : 512K

Consistency Policy : bitmap

    Reshape Status : 38% complete

    Number   Major   Minor   RaidDevice State
       0       8       17        0      faulty   /dev/sdb1
       1       8       65        1      faulty   /dev/sde1
       3       8       49        2      faulty   /dev/sdd1
       4       8       33        3      faulty   /dev/sdc1

Criei o RAID5 com 3 discos SSD de 1 TB e usei-o completamente para LVM. Ontem adicionei um quarto disco SSD de 1 TB e executei os seguintes comandos:

mdadm --add /dev/md126 /dev/sdc1
mdadm --grow /dev/md126 --raid-devices=4

No início não houve problema. O RAID5 ainda estava ativo e acessível lentamente. Cerca de 4 horas depois, algo deve ter acontecido. Esta manhã eu verifiquei e o status mdadmnão mudou, mas perdi meu RAID5 no LVM, embora os LVs ainda estejam montados, mas de alguma forma danificados.

Com dmesgeu recebo erros como:

[81591.695415] EXT4-fs (dm-5): I/O error while writing superblock
[81591.710467] EXT4-fs error (device dm-5): __ext4_get_inode_loc_noinmem:4617: inode #524289: block 2097184: comm ls: unable to read itable block
[81591.710488] Buffer I/O error on dev dm-5, logical block 0, lost sync page write
[81591.710495] EXT4-fs (dm-5): I/O error while writing superblock
[82806.711267] sd 0:0:0:0: [sdb] tag#8 FAILED Result: hostbyte=DID_BAD_TARGET driverbyte=DRIVER_OK cmd_age=0s
[82806.711279] sd 0:0:0:0: [sdb] tag#8 CDB: ATA command pass through(16) 85 06 2c 00 00 00 00 00 00 00 00 00 00 00 e5 00
[82806.711333] sd 5:0:0:0: [sdc] tag#9 FAILED Result: hostbyte=DID_BAD_TARGET driverbyte=DRIVER_OK cmd_age=0s
[82806.711339] sd 5:0:0:0: [sdc] tag#9 CDB: ATA command pass through(16) 85 06 2c 00 00 00 00 00 00 00 00 00 00 00 e5 00
[82806.711382] sd 4:0:0:0: [sdd] tag#11 FAILED Result: hostbyte=DID_BAD_TARGET driverbyte=DRIVER_OK cmd_age=0s
[82806.711388] sd 4:0:0:0: [sdd] tag#11 CDB: ATA command pass through(16) 85 06 2c 00 00 00 00 00 00 00 00 00 00 00 e5 00
[82806.711431] sd 1:0:0:0: [sde] tag#21 FAILED Result: hostbyte=DID_BAD_TARGET driverbyte=DRIVER_OK cmd_age=0s
[82806.711436] sd 1:0:0:0: [sde] tag#21 CDB: ATA command pass through(16) 85 06 2c 00 00 00 00 00 00 00 00 00 00 00 e5 00

O mdadm --examine --scannão fornece nenhuma saída, apenas para. O conteúdo atual é:

# automatically tag new arrays as belonging to the local system
HOMEHOST <system>

# instruct the monitoring daemon where to send mail alerts
MAILADDR root

# definitions of existing MD arrays
ARRAY /dev/md126 level=raid5 num-devices=3 metadata=1.2 name=horus:0 UUID=b187df52:41d7a47e:98e7fa00:cae9bf67
   devices=/dev/sda1,/dev/sdb1,/dev/sdc1

Parece que os superblocos MD desapareceram:

root@horus:~# mdadm --examine /dev/sd[abcde]1
/dev/sda1:
   MBR Magic : aa55
Partition[0] :    234441647 sectors at            1 (type ee)
mdadm: No md superblock detected on /dev/sdb1.
mdadm: No md superblock detected on /dev/sdc1.
mdadm: No md superblock detected on /dev/sdd1.
mdadm: No md superblock detected on /dev/sde1.

Olhando agora percebo que os dispositivos não estavam corretos. Desde 2021 os aparelhos devem ter mudado.

Sempre houve algo estranho no meu RAID5. Ele mudou de /dev/md0e /dev/md127para trás de vez em quando e agora, depois de adicionar o quarto disco, /dev/md126.

O problema começou com:

Aug 19 10:18:20 horus kernel: [ 1787.252546] md: reshape of RAID array md126
Aug 19 14:53:31 horus kernel: [18298.539238] ahci 0000:01:00.1: AMD-Vi: Event logged [IO_PAGE_FAULT domain=0x000d address=0xdfd6c000 flags=0x0000]
Aug 19 14:53:31 horus kernel: [18298.835872] ata6.00: exception Emask 0x10 SAct 0xe0000 SErr 0x0 action 0x6 frozen
Aug 19 14:53:31 horus kernel: [18298.835898] ata6.00: irq_stat 0x08000000, interface fatal error
Aug 19 14:53:31 horus kernel: [18298.835914] ata6.00: failed command: WRITE FPDMA QUEUED
Aug 19 14:53:31 horus kernel: [18298.835925] ata6.00: cmd 61/18:88:68:86:ee/00:00:2c:00:00/40 tag 17 ncq dma 12288 out
Aug 19 14:53:31 horus kernel: [18298.835925]          res 40/00:98:80:86:ee/00:00:2c:00:00/40 Emask 0x10 (ATA bus error)
Aug 19 14:53:31 horus kernel: [18298.835962] ata6.00: status: { DRDY }
Aug 19 14:53:31 horus kernel: [18298.835973] ata6.00: failed command: WRITE FPDMA QUEUED
Aug 19 14:53:31 horus kernel: [18298.835985] ata6.00: cmd 61/18:90:80:8a:ee/00:00:2c:00:00/40 tag 18 ncq dma 12288 out
Aug 19 14:53:31 horus kernel: [18298.835985]          res 40/00:98:80:86:ee/00:00:2c:00:00/40 Emask 0x10 (ATA bus error)
Aug 19 14:53:31 horus kernel: [18298.836022] ata6.00: status: { DRDY }
Aug 19 14:53:31 horus kernel: [18298.836034] ata6.00: failed command: WRITE FPDMA QUEUED
Aug 19 14:53:31 horus kernel: [18298.836045] ata6.00: cmd 61/18:98:80:86:ee/00:00:2c:00:00/40 tag 19 ncq dma 12288 out
Aug 19 14:53:31 horus kernel: [18298.836045]          res 40/00:98:80:86:ee/00:00:2c:00:00/40 Emask 0x10 (ATA bus error)
Aug 19 14:53:31 horus kernel: [18298.836082] ata6.00: status: { DRDY }
Aug 19 14:53:31 horus kernel: [18298.836096] ata6: hard resetting link

Parece que o último disco inserido morreu durante o crescimento .

Existe uma solução para isso? Devo parar mdadme reiniciar o cultivo? Outra coisa?

linux

1 respostas

  1. Best Answer

    Decidi reiniciar meu servidor. Como perdi um disco durante o crescimento e minha configuração do LVM, queria começar a recriação o mais rápido possível.

    Após a reinicialização, meus discos voltaram e também a configuração do LVM. mdadmcontinuei a crescer e depois de 4 horas terminou e parece que não perdi nenhum dado.

    O que causou o problema sempre permanecerá uma questão. Mas a reinicialização durante o crescimento não resultou em perda de dados.

    • 1

relate perguntas