Gosta! Que salmoura. vamos ver se conseguimos te organizar. Começando com uma recapitulação dos seus discos e tabelas de partições:
sda - no partition table
sdb - sdb1 [Linux] sdb2 [Linux extended] sdb5 [swap]
sdc - no partition table
sdd - no partition table
sde - no partition table
- Nenhum destes está marcado como fd autodetect do raid do Linux , que é o padrão
- Você não está usando partições para organizar seu espaço em disco [0]
- Parece que você tem todo o disco formatado para ext2 / 3 e estão usando todo o disco como parte do raidset
O último ponto é onde eu acho que você foi desfeito. Os initscripts provavelmente achavam que você estava precisando de um fsck, a sanidade verificou os volumes e eliminou o superbloco MD no processo. dumpe2fs não deve retornar nada para volumes do conjunto RAID .
Tome meu RAID por exemplo:
root@mark21:/tmp/etc/udev# fdisk -l /dev/sda
Disk /dev/sda: 640.1 GB, 640135028736 bytes
255 heads, 63 sectors/track, 77825 cylinders, total 1250263728 sectors
Units = sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disk identifier: 0x0000ffc4
Device Boot Start End Blocks Id System
/dev/sda1 2048 1240233983 620115968 fd Linux raid autodetect
root@mark21:/tmp/etc/udev# dumpe2fs /dev/sda1
dumpe2fs 1.41.14 (22-Dec-2010)
dumpe2fs: Bad magic number in super-block while trying to open /dev/sda
Couldn't find valid filesystem superblock.
O fato de você conseguir recriar o conjunto de RAIDs é extremamente sortudo, mas isso não altera as falhas fundamentais da sua implantação. Isso acontecerá novamente .
O que eu recomendaria é:
- Fazer backup de tudo nesse conjunto de invasores
- Destrua o array e apague o superbloco md de cada dispositivo (man mdadm)
- Zero esses discos:
dd if=/dev/zero of=/dev/sdX bs=1M count=100 - Crie partições em sda, sdc, sdd e & amp; sdf que abrangem 99% do disco [0]
- Marque essas partições como
type fdwiki linux-raid - nunca formata essas partições com qualquer tipo de sistema de arquivos
- Crie um novo RAID 5: mdadm --criar / dev / md0 -v -f -l 5 -n 4 / dev / sda1 / dev / sdc1 / dev / sdd1 / dev / sde1
- Atualize o novo UUID em /etc/mdadm.conf
- Viver feliz para sempre
Eu presumo da sua descrição que o sdb é o disco do seu sistema, e tudo bem. Apenas certifique-se de não incluir isso acidentalmente na sua criação do conjunto de raid. Depois disso, você deve estar no caminho certo e nunca mais encontrará esse problema.
[0] Eu encontrei uma falha muito desagradável uma vez em discos SATA que tinham muitos blocos ruins. Depois de usar a ferramenta do fornecedor para reconstituir o disco. Meu conjunto de discos uma vez idêntico era agora único, o disco defeituoso tinha alguns blocos a menos do que antes do início do formato de baixo nível, o que naturalmente arruinou minha tabela de partições e impediu que a unidade fosse re-conectada ao conjunto RAID MD.
Os discos rígidos geralmente têm uma "lista livre" de blocos de backup usados apenas por uma ocasião. Minha teoria é que essa lista deve ter sido esgotada, e como isso não era um disco corporativo, em vez de falhar e permitir a oportunidade de enviá-la para recuperação de dados, ela decidiu truncar meus dados e redimensionar a totalidade disco em.
Portanto, eu nunca mais uso o disco inteiro ao criar um conjunto RAID e, em vez disso, uso de 95 a 99% do espaço livre disponível ao criar uma partição que normalmente ocuparia todo o disco. Isso também lhe dá alguma flexibilidade adicional ao substituir membros com falha. Por exemplo, nem todos os discos de 250 GB têm a mesma quantidade de blocos livres, portanto, se você ultrapassar o máximo por uma margem confortável, poderá usar quase qualquer marca de disco para substituir um membro com falha.