Nova reconstrução do array Raid-1 2ª vez após a ativação

1

Eu criei um software-raid-1 a partir de uma partição de dados existente usando este tutorial . Ambos os discos são usb de 1TB, (cada um já tinha duas partições e eu usei 2 de cada, elas têm o mesmo tamanho)

Então eu simplesmente reparticionei o disco B com o tipo fd e criei o array

mdadm --create /dev/md0 --level=1 --raid-devices=2 missing /dev/sdf2

formatou-o (reiserfs), montou-o, copiou dados nele.

Eu usei o kit de dispositivos gnome (?) (= Laufwerksverwaltung) para fazer um pouco disso. Não tenho certeza se isso me causou problemas.

Coloque no mdadm.conf a linha

ARRAY /dev/md0 level=raid1 num-devices=2 UUID=07e09d37:975bfef4:80073a9f:2aa04953

Adicionado ao fstab:

UUID=07e09d37-975b-fef4-8007-3a9f2aa04953 none  auto    nouser,noauto   0   0
/dev/md0    /media/md0  reiserfs    defaults    0   0

Eu habilitei de alguma forma e começou a reconstruir. Demorou muito tempo (muitos arquivos pequenos).

Eu montei e verifiquei o conteúdo. Então eu queria testar a remoção de uma unidade. Disposição desmontada de curso e comutada de um disco, matriz montada novamente, conteúdo bem.

Não tenho certeza se algo de errado aconteceu; pelo menos eu testei a reinicialização e de alguma forma a reconstrução começou de novo.

Depois de finalmente ter todos reconstruído, o array ainda estava degradado. Então, decidi parar com o gerenciador de dispositivos e executar o cheque. Após a reativação, começou novamente a reconstrução.

Qual é o problema aqui? Ajude-me a entender os processos na invasão de software.

Mais algumas informações:

root@grooverunner:~# mdadm --detail /dev/md0
/dev/md0:
        Version : 00.90
  Creation Time : Sat Apr 30 00:19:23 2011
     Raid Level : raid1
     Array Size : 452462592 (431.50 GiB 463.32 GB)
  Used Dev Size : 452462592 (431.50 GiB 463.32 GB)
   Raid Devices : 2
  Total Devices : 2
Preferred Minor : 0
    Persistence : Superblock is persistent

    Update Time : Sat Apr 30 21:16:15 2011
          State : clean, degraded, recovering
 Active Devices : 1
Working Devices : 2
 Failed Devices : 0
  Spare Devices : 1

 Rebuild Status : 5% complete

           UUID : 07e09d37:975bfef4:80073a9f:2aa04953 (local to host grooverunner)
         Events : 0.1198

    Number   Major   Minor   RaidDevice State
       2       8       50        0      spare rebuilding   /dev/sdd2
       1       8       66        1      active sync   /dev/sde2

Minhas perguntas relacionadas são:

  1. A reconstrução sempre copia tudo de novo?
  2. Qual é o oposto do mdadm --assemble?
por groovehunter 30.04.2011 / 21:36

1 resposta

1

Sempre que um ataque md entrar em estado degradado, será necessária uma reconstrução. Uma reconstrução sempre sincronizará novamente todo o disco.

A reconstrução do teste de remoção da sua unidade terminou antes da reinicialização? E o que disse quando foi "ainda degradado" após a reconstrução? Se não estiver saindo de um estado degradado quando uma reconstrução for concluída, esse será seu verdadeiro problema. Aguarde a conclusão da reconstrução e, em seguida, verifique a saída de mdadm --detail ou cat /proc/mdstat .

mdadm --stop é o oposto de montar.

    
por 01.05.2011 / 02:36