Como fazer com que um dispositivo RAID inativo funcione novamente?

Após a inicialização, meu dispositivo RAID1 ( /dev/md_d0*) às vezes entra em um estado engraçado e não consigo montá-lo.

^{* Originalmente eu criei, /dev/md0mas ele de alguma forma se transformou em /dev/md_d0.}

# mount /opt
mount: wrong fs type, bad option, bad superblock on /dev/md_d0,
       missing codepage or helper program, or other error
       (could this be the IDE device where you in fact use
       ide-scsi so that sr0 or sda or so is needed?)
       In some cases useful info is found in syslog - try
       dmesg | tail  or so

O dispositivo RAID parece estar inativo de alguma forma:

# cat /proc/mdstat
Personalities : [linear] [multipath] [raid0] [raid1] [raid6] [raid5] 
                [raid4] [raid10] 
md_d0 : inactive sda4[0](S)
      241095104 blocks

# mdadm --detail /dev/md_d0
mdadm: md device /dev/md_d0 does not appear to be active.

A questão é: como tornar o dispositivo ativo novamente (usando mdmadm, presumo)?

(Outras vezes, está tudo bem (ativo) após a inicialização, e eu posso montá-lo manualmente sem problemas. Mas ele ainda não será montado automaticamente, mesmo que eu o tenha /etc/fstab:

/dev/md_d0        /opt           ext4    defaults        0       0

Então, uma pergunta bônus: o que devo fazer para que o dispositivo RAID seja montado automaticamente /optno momento da inicialização? )

Esta é uma estação de trabalho Ubuntu 9.10. Informações de plano de fundo sobre minha configuração de RAID nesta pergunta .

Edit : Minha /etc/mdadm/mdadm.confaparência é assim. Nunca toquei neste arquivo, pelo menos à mão.

# by default, scan all partitions (/proc/partitions) for MD superblocks.
# alternatively, specify devices to scan, using wildcards if desired.
DEVICE partitions

# auto-create devices with Debian standard permissions
CREATE owner=root group=disk mode=0660 auto=yes

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

# instruct the monitoring daemon where to send mail alerts
MAILADDR <my mail address>

# definitions of existing MD arrays

# This file was auto-generated on Wed, 27 Jan 2010 17:14:36 +0200

Na /proc/partitionsúltima entrada, md_d0pelo menos agora, após a reinicialização, quando o dispositivo estiver ativo novamente. (Não tenho certeza se seria o mesmo quando estiver inativo.)

Resolução : como Jimmy Hedman sugeriu , peguei a saída de mdadm --examine --scan:

ARRAY /dev/md0 level=raid1 num-devices=2 UUID=de8fbd92[...]

e acrescentou /etc/mdadm/mdadm.conf, o que parece ter corrigido o problema principal. Depois de mudar /etc/fstabpara usar /dev/md0novamente (em vez de /dev/md_d0), o dispositivo RAID também é montado automaticamente!

Para sua pergunta bônus:

mdadm --examine --scan >> /etc/mdadm/mdadm.conf

Descobri que preciso adicionar a matriz manualmente /etc/mdadm/mdadm.confpara que o Linux a monte na reinicialização. Caso contrário, recebo exatamente o que você tem aqui - md_d1dispositivos que estão inativos etc.

O arquivo conf deve se parecer com abaixo - isto é, uma ARRAYlinha para cada dispositivo md. No meu caso, as novas matrizes estavam ausentes neste arquivo, mas se você as tiver listado, provavelmente não será uma correção para o seu problema.

# definitions of existing MD arrays
ARRAY /dev/md0 level=raid5 num-devices=3 UUID=f10f5f96:106599e0:a2f56e56:f5d3ad6d
ARRAY /dev/md1 level=raid1 num-devices=2 UUID=aa591bbe:bbbec94d:a2f56e56:f5d3ad6d

Adicione uma matriz por dispositivo md e adicione-a após o comentário incluído acima, ou se esse comentário não existir, no final do arquivo. Você obtém os UUIDs fazendo sudo mdadm -E --scan:

$ sudo mdadm -E --scan
ARRAY /dev/md0 level=raid5 num-devices=3 UUID=f10f5f96:106599e0:a2f56e56:f5d3ad6d
ARRAY /dev/md1 level=raid1 num-devices=2 UUID=aa591bbe:bbbec94d:a2f56e56:f5d3ad6d

Como você pode ver, você pode simplesmente copiar a saída do resultado da verificação para o arquivo.

Eu corro o ubuntu desktop 10.04 LTS e, tanto quanto me lembro, esse comportamento difere da versão do servidor do Ubuntu, no entanto, há tanto tempo atrás eu criei meus dispositivos md no servidor, posso estar errado. Também pode ser que eu tenha perdido alguma opção.

De qualquer forma, adicionar a matriz no arquivo conf parece fazer o truque. Eu executei o ataque acima 1 e o ataque 5 por anos sem problemas.

Aviso: Antes de tudo, deixe-me dizer que o abaixo (devido ao uso de "--force") parece arriscado para mim e, se você tiver dados irrecuperáveis, recomendo fazer cópias das partições envolvidas antes de começar a tentar qualquer um dos as coisas abaixo. No entanto, isso funcionou para mim.

Eu tive o mesmo problema, com uma matriz aparecendo como inativa, e nada do que fiz incluindo o "mdadm --examine --scan> /etc/mdadm.conf", como sugerido por outras pessoas aqui, ajudou em tudo.

No meu caso, quando tentou iniciar o array RAID-5 após a substituição da unidade, estava dizendo que estava sujo (via dmesg):

md/raid:md2: not clean -- starting background reconstruction
md/raid:md2: device sda4 operational as raid disk 0
md/raid:md2: device sdd4 operational as raid disk 3
md/raid:md2: device sdc4 operational as raid disk 2
md/raid:md2: device sde4 operational as raid disk 4
md/raid:md2: allocated 5334kB
md/raid:md2: cannot start dirty degraded array.

Fazendo com que ele apareça como inativo em /proc/mdstat:

md2 : inactive sda4[0] sdd4[3] sdc4[2] sde4[5]
      3888504544 blocks super 1.2

Descobri que todos os dispositivos tinham os mesmos eventos, exceto a unidade que eu havia substituído ( /dev/sdb4):

[root@nfs1 sr]# mdadm -E /dev/sd*4 | grep Event
mdadm: No md superblock detected on /dev/sdb4.
         Events : 8448
         Events : 8448
         Events : 8448
         Events : 8448

No entanto, os detalhes da matriz mostraram que havia 4 de 5 dispositivos disponíveis:

[root@nfs1 sr]# mdadm --detail /dev/md2
/dev/md2:
[...]
   Raid Devices : 5
  Total Devices : 4
[...]
 Active Devices : 4
Working Devices : 4
[...]
    Number   Major   Minor   RaidDevice State
       0       8        4        0      inactive dirty  /dev/sda4
       2       8       36        2      inactive dirty  /dev/sdc4
       3       8       52        3      inactive dirty  /dev/sdd4
       5       8       68        4      inactive dirty  /dev/sde4

(O texto acima é da memória na coluna "State", não consigo encontrá-lo no meu buffer de rolagem para trás).

Consegui resolver isso parando a matriz e remontando-a:

mdadm --stop /dev/md2
mdadm -A --force /dev/md2 /dev/sd[acde]4

Nesse ponto, o array estava funcionando, rodando com 4 dos 5 dispositivos, e eu pude adicionar o dispositivo de substituição e ele está sendo reconstruído. Consigo acessar o sistema de arquivos sem nenhum problema.

Eu estava tendo problemas com o Ubuntu 10.04, onde um erro no FStab impedia a inicialização do servidor.

Eu executei este comando conforme mencionado nas soluções acima:

mdadm --examine --scan >> /etc/mdadm/mdadm.conf

Isso anexará os resultados de "mdadm --examine --scan" a "/etc/mdadm/mdadm.conf"

No meu caso, isso foi:

ARRAY /dev/md/0 metadata=1.2 UUID=2660925e:6d2c43a7:4b95519e:b6d110e7 name=localhost:0

Este é um 0. fakeraid. Meu comando no / etc / fstab para montagem automática é:

/dev/md0 /home/shared/BigDrive ext3 defaults,nobootwait,nofail 0 0

O importante aqui é que você tem "nobootwait" e "nofail". O Nobootwait ignorará qualquer mensagem do sistema que esteja impedindo a inicialização. No meu caso, isso estava em um servidor remoto, por isso era essencial.

Espero que isso ajude algumas pessoas.

Você pode ativar seu dispositivo md com

mdadm -A /dev/md_d0

Suponho que algum script de inicialização seja iniciado muito cedo, antes que um membro do RAID seja descoberto ou algum problema semelhante. Como uma solução rápida e suja, você deve poder adicionar esta linha ao /etc/rc.local:

mdadm -A /dev/md_d0 && mount /dev/md_d0

Edit: aparentemente seu /etc/mdadm/mdadm.conf ainda contém o nome da configuração antiga. Edite esse arquivo e substitua as ocorrências de md0 por md_d0.

Eu tive um problema semelhante ... meu servidor não montaria o md2 depois de aumentar as partições de dispositivos associados. Ao ler este tópico, descobri que o dispositivo RAID md2 tinha um novo UUID e a máquina estava tentando usar o antigo.

Conforme sugerido ... usando a saída 'md2' de

mdadm --examine --scan

Eu editei /etc/mdadm/mdadm.confe substitui a linha UUID antiga pela saída acima do comando e meu problema desapareceu.

Quando você finge fazer algo com /dev/md[012346789}isso, vai /dev/md{126,127...}. /dev/md0continua montado /dev/md126ou /dev/md127você precisa:

quantidade /dev/md127 ou quantidade /dev/md126.

Isso é temporário para permitir que você execute comandos e alguns aplicativos sem parar o sistema.

md_d0 : inactive sda4[0](S)parece errado para uma matriz RAID1. Parece sugerir que o array não possui dispositivos ativos e um dispositivo sobressalente ^{_{(indicado por (S), você veria (F) um dispositivo com falha e nada para um dispositivo OK / ativo)}} - para um array RAID1 que não seja está executando degradado, deve haver pelo menos dois dispositivos OK / ativos ^{_{(e para uma matriz degradada, pelo menos um dispositivo OK / ativo)}} e você não pode ativar uma matriz RAID1 sem dispositivos não sobressalentes que não falhem (como peças de reposição não contenha uma cópia dos dados até que sejam ativados quando outra unidade falhar). Se eu estiver lendo /proc/mdstatcorretamente essa saída, você não poderá ativar a matriz em seu estado atual.

Você tem alguma unidade física na máquina que falhou ao girar? Será que ls /dev/sd*lista todas as unidades e partições que você normalmente esperaria para ver nessa máquina?

Uma maneira simples de executar a matriz, assumindo que não há problema de hardware e que você tenha unidades / partições suficientes para iniciar a matriz, é o seguinte:

md20 : inactive sdf1[2](S)
      732442488 blocks super 1.2

 sudo mdadm --manage /dev/md20  --run

Pode ser que, por qualquer motivo, a matriz esteja correta, mas algo tenha impedido sua inicialização ou construção. No meu caso, isso ocorreu porque o mdadm não sabia que o nome original da matriz era md127 e todas as unidades foram desconectadas para essa matriz. Ao recarregar, tive que montar manualmente (provavelmente um erro em que o mdadm achava que o array já estava ativo por causa do nome antigo e offline do array).