Recuperar a matriz RAID5 do software Linux após a atualização do servidor

Question

Eu atualizei recentemente um servidor do Fedora 6 para o Fedora 14. Além do disco rígido principal onde o sistema operacional está instalado, eu tenho 3 discos rígidos de 1 TB configurados para o RAID5 (via software). Após a atualização, notei que um dos discos rígidos havia sido removido da matriz de ataque. Eu tentei adicioná-lo de volta com o mdadm --add, mas ele apenas o colocou como sobressalente. Eu imaginei que voltaria depois.

Então, ao executar uma reinicialização, o sistema não pôde montar o array de ataque. Eu o removi do fstab para poder inicializar o sistema e agora estou tentando fazer o array do RAID voltar.

Eu corri o seguinte:

mdadm --create /dev/md0 --assume-clean --level=5 --chunk=64 --raid-devices=3 missing /dev/sdc1 /dev/sdd1

Eu sei que o tamanho do meu bloco é 64k, e "missing" é para o drive que foi expulso do array (/ dev / sdb1).

Isso pareceu funcionar, e o mdadm relata que a matriz está sendo executada "limpa, degradada" com a unidade ausente.

No entanto, não consigo montar o array de raid. Quando eu tento:

mount -t ext3 /dev/md0 /mnt/foo

Eu recebo:

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

e / var / log / messages mostra:

EXT3-fs (md0): error: can't find ext3 filesystem on dev md0.

Alguém tem alguma ideia do que tentar em seguida?

    

Answer 1

Você pode ter o missing na posição errada. Somente a posição correta das unidades e missing funcionarão. Basta executar:

mdadm --examine  /dev/sdb1

Isso produzirá (entre outras coisas) a informação de que número no RAID está realmente ausente. Procure a linha this :

      Number   Major   Minor   RaidDevice State
this     0     253       13        0      active sync   /dev/dm-13

Nesse caso, é o número 0 (= primeiro dispositivo) e active , pois o RAID está on-line no momento. Agora você sabe que a unidade deve ser especificada como missing .

Mas você ainda tem duas opções: A ordem das unidades trabalhando também precisa ser trocada. Essa informação é perdida, no entanto, porque foi sobrescrita por sua tentativa de remontagem.

    

Answer 2

uma das coisas que descobri é que mdadm --create /dev/md0 --assume-clean só funcionará corretamente se você usar a mesma versão (ou próxima) do mdadm que foi usada para criar uma matriz original. Isso é porque eles usam diferentes offsets para dados e metadados, mesmo se a versão do mesmo superbloco (como 1.2)

O problema é que a saída do mdadm sempre diz que foi recriado o array, mas os dados contidos em / dev / md0 estarão errados.

por exemplo, usar o mdadm 3.3.2 recente ou o 3.2.5 anterior não funcionou para mim, mas voltar ao mdadm 3.1.4 (que criou o array) funcionou muito bem.

Observe que também tomei o cuidado de especificar unidades na ordem correta (conforme detalhado em mdadm --examine /dev/sd? ) ao recriar o array e usar arquivos de sobreposição para todos os testes (para não aumentar o dano), usando instruções em link

No meu caso, o problema era o RAID5 de 6 discos, que estava crescendo para 7 discos, mas não progrediu, então foi interrompido e não seria mais compilado com mdadm: Failed to restore critical section for reshape, sorry. e --force e --invalid-backup não estava ajudando, então eu tive que usar --create --assume-clean