mdadm RAID - Reinicie durante o Grow (Shrink), remodele - não funciona (não funciona)

Navegue suas respostas
3

Eu tenho um array Linux Raid6 array (mdadm). Eu cresci de 6x4TB discos (16TB utilizável) para 7x4TB (20TB utilizável). A reformulação correu bem, mas quando fiz resize2fs, recebi o problema bem conhecido do limite do sistema de arquivos EXT4 de 16TB. Eu verifiquei e o sistema de arquivos NÃO tem o sinalizador de 64 bits. Então, em um esforço para recuperar a unidade extra que acabei de adicionar à matriz, fiz isso: 

johnny@debian:~$ sudo resize2fs /dev/md0 16000G
johnny@debian:~$ sudo mdadm --grow /dev/md0 --array-size=16000G
johnny@debian:~$ sudo mdadm --grow /dev/md0 --raid-devices=6 --backup-file=/tmp/backup

Observe o local do arquivo de backup. Isso vai ser importante em um minuto, porque eu estou no Debian.

Então as coisas estavam indo bem, lentas, mas funcionando. O progresso chegou a 3,7% e diminuiu a velocidade. Eu tinha assumido que isso era porque eu estava reformulando algumas outras matrizes durante esse mesmo tempo. Quando os outros trabalhos terminaram e este não acelerou, fiquei muito preocupado. Como disse que levaria anos para terminar, decidi que deveria reiniciar e ver se aceleraria, então reiniciei o sistema.

É quando coisas ruins começam a acontecer ...

Estou no Debian, e entendo que a pasta / tmp é eliminada quando o sistema é ativado, então meu arquivo de backup do reshape foi perdido. Além disso, como meu arquivo / etc / fstab estava tentando montar o md0, que não estava sendo montado agora, o sistema falhou em aparecer algumas vezes. Eu comecei de um live cd e consertei o arquivo fstab e fiz o sistema voltar.

Uma vez que eu resolvi isso, o sistema estava pronto, e essa foi a primeira vez que vi que o md0 não tinha simplesmente se montado e continuado a remodelação. Pânico definido em ...

Eu não tenho a saída dos seguintes comandos, mas eu consegui encontrar os comandos que eu digitei. Breve explicação do que aconteceu a seguir ... 

johnny@debian:~$ sudo mdadm --assemble /dev/md0
johnny@debian:~$ sudo mdadm --assemble --force /dev/md0
johnny@debian:~$ sudo mdadm --assemble --force /dev/md0 --backup-file=/tmp/backup

O primeiro comando falhou, então eu tentei a opção --force, que também falhou, mas a mensagem de erro me disse que a falha era porque precisava da opção --backup-file, então executei o terceiro comando. Eu esperava que o arquivo de backup ainda existisse, mas não porque estava na pasta / tmp e havia sido excluído. Isso não parece causar nenhum problema, porque a matriz foi montada.

Aqui está o que o md0 parece agora. Observe o disco marcado como "removido". Eu suspeito que este é o disco que estava sendo removido, sdj1. 

johnny@debian:~$ sudo mdadm --detail /dev/md0
/dev/md0:
        Version : 1.2
  Creation Time : Fri Jan 11 09:59:42 2013
     Raid Level : raid6
     Array Size : 15627548672 (14903.59 GiB 16002.61 GB)
  Used Dev Size : 3906887168 (3725.90 GiB 4000.65 GB)
   Raid Devices : 6
  Total Devices : 6
    Persistence : Superblock is persistent

  Intent Bitmap : Internal

    Update Time : Sat Mar  5 20:45:56 2016
          State : clean, degraded, reshaping 
 Active Devices : 6
Working Devices : 6
 Failed Devices : 0
  Spare Devices : 0

         Layout : left-symmetric
     Chunk Size : 512K

 Reshape Status : 3% complete
  Delta Devices : -1, (7->6)

           Name : BigRaid6
           UUID : 45747bdc:ba5a85fe:ead35e14:24c2c7b2
         Events : 4339739

    Number   Major   Minor   RaidDevice State
      11       8      224        0      active sync   /dev/sdo
       2       0        0        2      removed
       6       8       80        2      active sync   /dev/sdf
       7       8      176        3      active sync   /dev/sdl
      12       8       16        4      active sync   /dev/sdb
       8       8       32        5      active sync   /dev/sdc

       9       8      128        6      active sync   /dev/sdi

E aqui está o progresso atual da reformulação. Observe que está completamente preso a 0K / seg. 

johnny@debian:~$ cat /proc/mdstat
Personalities : [raid1] [raid6] [raid5] [raid4] 
md0 : active raid6 sdo[11] sdi[9] sdc[8] sdb[12] sdl[7] sdf[6]
      15627548672 blocks super 1.2 level 6, 512k chunk, algorithm 2 [6/5] [U_UUUU]
      [>....................]  reshape =  3.7% (145572864/3906887168) finish=284022328345.0min speed=0K/sec
      bitmap: 5/30 pages [20KB], 65536KB chunk

unused devices: <none>

Aqui estão os discos individuais ainda na matriz. 

johnny@debian:~$ sudo mdadm --examine /dev/sd[oflbci]
/dev/sdb:
          Magic : a92b4efc
        Version : 1.2
    Feature Map : 0x5
     Array UUID : 45747bdc:ba5a85fe:ead35e14:24c2c7b2
           Name : BigRaid6
  Creation Time : Fri Jan 11 09:59:42 2013
     Raid Level : raid6
   Raid Devices : 6

 Avail Dev Size : 7813775024 (3725.90 GiB 4000.65 GB)
     Array Size : 15627548672 (14903.59 GiB 16002.61 GB)
  Used Dev Size : 7813774336 (3725.90 GiB 4000.65 GB)
    Data Offset : 262144 sectors
   Super Offset : 8 sectors
   Unused Space : before=262064 sectors, after=688 sectors
          State : clean
    Device UUID : 99b0fbcc:46d619bb:9ae96eaf:840e21a4

Internal Bitmap : 8 sectors from superblock
  Reshape pos'n : 15045257216 (14348.28 GiB 15406.34 GB)
  Delta Devices : -1 (7->6)

    Update Time : Sat Mar  5 20:45:56 2016
       Checksum : fca445bd - correct
         Events : 4339739

         Layout : left-symmetric
     Chunk Size : 512K

   Device Role : Active device 4
   Array State : A.AAAAA ('A' == active, '.' == missing, 'R' == replacing)
/dev/sdc:
          Magic : a92b4efc
        Version : 1.2
    Feature Map : 0x5
     Array UUID : 45747bdc:ba5a85fe:ead35e14:24c2c7b2
           Name : BigRaid6
  Creation Time : Fri Jan 11 09:59:42 2013
     Raid Level : raid6
   Raid Devices : 6

 Avail Dev Size : 7813775024 (3725.90 GiB 4000.65 GB)
     Array Size : 15627548672 (14903.59 GiB 16002.61 GB)
  Used Dev Size : 7813774336 (3725.90 GiB 4000.65 GB)
    Data Offset : 262144 sectors
   Super Offset : 8 sectors
   Unused Space : before=262064 sectors, after=688 sectors
          State : clean
    Device UUID : b8d49170:06614f82:ad9a38a4:e9e06da5

Internal Bitmap : 8 sectors from superblock
  Reshape pos'n : 15045257216 (14348.28 GiB 15406.34 GB)
  Delta Devices : -1 (7->6)

    Update Time : Sat Mar  5 20:45:56 2016
       Checksum : 5d867810 - correct
         Events : 4339739

         Layout : left-symmetric
     Chunk Size : 512K

   Device Role : Active device 5
   Array State : A.AAAAA ('A' == active, '.' == missing, 'R' == replacing)
/dev/sdf:
          Magic : a92b4efc
        Version : 1.2
    Feature Map : 0x5
     Array UUID : 45747bdc:ba5a85fe:ead35e14:24c2c7b2
           Name : BigRaid6
  Creation Time : Fri Jan 11 09:59:42 2013
     Raid Level : raid6
   Raid Devices : 6

 Avail Dev Size : 7813775024 (3725.90 GiB 4000.65 GB)
     Array Size : 15627548672 (14903.59 GiB 16002.61 GB)
  Used Dev Size : 7813774336 (3725.90 GiB 4000.65 GB)
    Data Offset : 262144 sectors
   Super Offset : 8 sectors
   Unused Space : before=262064 sectors, after=688 sectors
          State : clean
    Device UUID : dd56062c:4b55bf16:6a468024:3ca6bfd0

Internal Bitmap : 8 sectors from superblock
  Reshape pos'n : 15045257216 (14348.28 GiB 15406.34 GB)
  Delta Devices : -1 (7->6)

    Update Time : Sat Mar  5 20:45:56 2016
       Checksum : 59045f87 - correct
         Events : 4339739

         Layout : left-symmetric
     Chunk Size : 512K

   Device Role : Active device 2
   Array State : A.AAAAA ('A' == active, '.' == missing, 'R' == replacing)
/dev/sdi:
          Magic : a92b4efc
        Version : 1.2
    Feature Map : 0x5
     Array UUID : 45747bdc:ba5a85fe:ead35e14:24c2c7b2
           Name : BigRaid6
  Creation Time : Fri Jan 11 09:59:42 2013
     Raid Level : raid6
   Raid Devices : 6

 Avail Dev Size : 7813775024 (3725.90 GiB 4000.65 GB)
     Array Size : 15627548672 (14903.59 GiB 16002.61 GB)
  Used Dev Size : 7813774336 (3725.90 GiB 4000.65 GB)
    Data Offset : 262144 sectors
   Super Offset : 8 sectors
   Unused Space : before=262064 sectors, after=688 sectors
          State : clean
    Device UUID : 92831abe:86de117c:710c368e:8badcef3

Internal Bitmap : 8 sectors from superblock
  Reshape pos'n : 15045257216 (14348.28 GiB 15406.34 GB)
  Delta Devices : -1 (7->6)

    Update Time : Sat Mar  5 20:45:56 2016
       Checksum : dd2fe2d1 - correct
         Events : 4339739

         Layout : left-symmetric
     Chunk Size : 512K

   Device Role : Active device 6
   Array State : A.AAAAA ('A' == active, '.' == missing, 'R' == replacing)
/dev/sdl:
          Magic : a92b4efc
        Version : 1.2
    Feature Map : 0x5
     Array UUID : 45747bdc:ba5a85fe:ead35e14:24c2c7b2
           Name : BigRaid6
  Creation Time : Fri Jan 11 09:59:42 2013
     Raid Level : raid6
   Raid Devices : 6

 Avail Dev Size : 7813775024 (3725.90 GiB 4000.65 GB)
     Array Size : 15627548672 (14903.59 GiB 16002.61 GB)
  Used Dev Size : 7813774336 (3725.90 GiB 4000.65 GB)
    Data Offset : 262144 sectors
   Super Offset : 8 sectors
   Unused Space : before=262064 sectors, after=688 sectors
          State : clean
    Device UUID : 8404647a:b1922fed:acf71f64:18dfd448

Internal Bitmap : 8 sectors from superblock
  Reshape pos'n : 15045257216 (14348.28 GiB 15406.34 GB)
  Delta Devices : -1 (7->6)

    Update Time : Sat Mar  5 20:45:56 2016
       Checksum : 358734b4 - correct
         Events : 4339739

         Layout : left-symmetric
     Chunk Size : 512K

   Device Role : Active device 3
   Array State : A.AAAAA ('A' == active, '.' == missing, 'R' == replacing)
/dev/sdo:
          Magic : a92b4efc
        Version : 1.2
    Feature Map : 0x5
     Array UUID : 45747bdc:ba5a85fe:ead35e14:24c2c7b2
           Name : BigRaid6
  Creation Time : Fri Jan 11 09:59:42 2013
     Raid Level : raid6
   Raid Devices : 6

 Avail Dev Size : 7813775024 (3725.90 GiB 4000.65 GB)
     Array Size : 15627548672 (14903.59 GiB 16002.61 GB)
  Used Dev Size : 7813774336 (3725.90 GiB 4000.65 GB)
    Data Offset : 262144 sectors
   Super Offset : 8 sectors
   Unused Space : before=262064 sectors, after=688 sectors
          State : clean
    Device UUID : d7e84765:86fb751a:466ab0de:c26afc43

Internal Bitmap : 8 sectors from superblock
  Reshape pos'n : 15045257216 (14348.28 GiB 15406.34 GB)
  Delta Devices : -1 (7->6)

    Update Time : Sat Mar  5 20:45:56 2016
       Checksum : c3698023 - correct
         Events : 4339739

         Layout : left-symmetric
     Chunk Size : 512K

   Device Role : Active device 0
   Array State : A.AAAAA ('A' == active, '.' == missing, 'R' == replacing

Aqui está / dev / sdj1, que costumava ser o único membro da matriz que não era um membro de "disco inteiro". Este foi o único a ser removido da matriz durante a reformulação. Eu suspeito que ainda é necessário terminar a remodelação, embora não seja atualmente um membro da matriz, porque tem os dados sobre isso antes da reformulação. 

johnny@debian:~$ sudo mdadm --examine /dev/sdj1
mdadm: No md superblock detected on /dev/sdj1.

Então, aqui estão meus problemas ...
1. Não consigo fazer a reforma terminar.
2. Não consigo montar o array. Quando eu tento, eu entendo isso. 

johnny@debian:~$ sudo mount /dev/md0 /media/BigRaid6
mount: wrong fs type, bad option, bad superblock on /dev/md0,
       missing codepage or helper program, or other error

       In some cases useful info is found in syslog - try
       dmesg | tail or so.
johnny@debian:~$ sudo dmesg | tail
[42446.268089] sd 15:0:0:0: [sdk]  
[42446.268091] Add. Sense: Unrecovered read error - auto reallocate failed
[42446.268092] sd 15:0:0:0: [sdk] CDB: 
[42446.268093] Read(10): 28 00 89 10 bb 00 00 04 00 00
[42446.268099] end_request: I/O error, dev sdk, sector 2299575040
[42446.268131] ata16: EH complete
[61123.788170] md: md1: data-check done.
[77423.597923] EXT4-fs (md0): bad geometry: block count 4194304000 exceeds size of device (3906887168 blocks)
[77839.250590] EXT4-fs (md0): bad geometry: block count 4194304000 exceeds size of device (3906887168 blocks)
[78525.085343] EXT4-fs (md0): bad geometry: block count 4194304000 exceeds size of device (3906887168 blocks)

Tenho certeza de que a montagem seria bem-sucedida se a remodelação fosse concluída, então provavelmente é o mais importante. Apenas FYI, os dados nesta matriz são muito grandes para serem armazenados em backup, então, se eu perdê-los, os dados desaparecem. Por favor ajude!

EDIT 1:

Eu poderia desembolsar $ 1000 (ou mais) e obter discos suficientes para copiar tudo, mas eu precisaria ser capaz de montar o array para que isso funcionasse.

Além disso, observei que a mensagem de erro "geometria incorreta" que recebo ao tentar montar o array contém algumas informações interessantes. 

[146181.331566] EXT4-fs (md0): bad geometry: block count 4194304000 exceeds size of device (3906887168 blocks)

O tamanho do dispositivo, 3906887168, é exatamente 1/4 do tamanho da matriz de md0, 15627548672. De "mdadm --detail / dev / md0" 

Array Size : 15627548672 (14903.59 GiB 16002.61 GB)

Não sei de onde vem o número 4194304000 ... mas isso não significa que o array tem o tamanho certo para caber nesses discos? Ou esses tamanhos não são responsáveis pelos metadados do mdadm? É 4194304000 incluindo os metadados, talvez?

Eu poderia jurar que tentei algumas vezes obter os tamanhos antes mesmo de a reformulação começar, então achei que estava tudo certo. Talvez eu estivesse errado.

    
por John 07.03.2016 / 00:02

1 resposta

1

Seu erro já está no primeiro comando, 16000GiB simplesmente não é o que você tem em discos 6x4TB, mesmo 16000GB pode ser um alongamento, pois você perde espaço para mdadm metadata e tal. A última mensagem de erro lembra bastante essa situação ( bad geometry , sistema de arquivos acredita ser maior que dispositivo oferece, e sistemas de arquivos absolutamente odeiam isso).

Então, você está analisando vários problemas no momento:

  • seu sistema de arquivos é muito grande
  • seu psiquiatra está preso no meio
  • pelo menos um dos seus discos falhou ( /dev/sdk )
  • seu arquivo de backup foi perdido
  • possíveis inconsistências do sistema de arquivos (obviamente)

A solução para o seu problema não é fazer com que o psiquiatra acabe de alguma forma, mas sim, reverter para o estado anterior sem danos ... isso pode ainda ser possível, pois felizmente o psiquiatra não progrediu muito longe ainda.

Nesta situação eu gostaria

Recriar o RAID é uma idéia muito, muito ruim em geral, já que quase sempre dá errado. No entanto, acho que no seu caso pode causar menos danos do que tentar reverter o processo de redução de qualquer outra forma. No RAID 6 de 7 discos, a área 16GiB ainda pode estar intocada ... supondo que o sistema de arquivos esteja ocioso enquanto o RAID está encolhendo. Caso contrário, você está vendo ainda mais inconsistências no sistema de arquivos.

Ao recriar o RAID, você precisa ter todas as variáveis corretas: versão de metadados, deslocamento de dados, nível de ataque, layout do ataque, tamanho do bloco, ordem de disco ... e você deve evitar -syncs deixando os discos de redundância como ausentes.

Pode ser assim: 

mdadm --create /dev/md0 --assume-clean \
    --metadata=1.2 --data-offset=128M --level=6 --layout=ls --chunk=512 \
    --raid-devices=7 missing missing /dev/mapper/overlay-{sdf,sdl,sdb,sdc,sdi}

Sem garantia, eu obviamente não tentei fazer isso sozinho.

Depois de verificar se funciona, você pode confirmar as alterações no disco (aplique as etapas verificadas para funcionar sem sobreposição). Então, desta vez, resize2fs do sistema de arquivos corretamente ( 14G deve funcionar), então reduza o RAID e espere que ele não fique preso novamente. Um arquivo de backup pode não ser necessário para mdadm --grow , se você usar um, certifique-se de não perdê-lo.

    
por 07.03.2016 / 00:55

Tags

Como conseguir que o BusyBox udhcpc seja executado em segundo plano para sempre? Existe um comando FreeDesktop para abrir uma caixa de diálogo aberta semelhante ao xdg-open?