Ok - algo estava me incomodando sobre o seu problema, então eu iniciei uma VM para mergulhar no comportamento que deveria ser esperado. Vou entender o que estava me incomodando em um minuto; primeiro deixe-me dizer o seguinte:
Faça backup dessas unidades antes de tentar qualquer coisa !!
Você já pode ter causado danos além do que a ressincronização fez; você pode esclarecer o que quis dizer quando disse:
Por sugestões, eu limpei os superblocos e recriei o array com a opção --assume-clean, mas sem sorte alguma.
Se você executou um mdadm --misc --zero-superblock, deve ficar bem.
De qualquer forma, vasculhe alguns discos novos e pegue as imagens atuais exatas deles antes de fazer qualquer coisa que possa fazer mais gravação nesses discos.
dd if=/dev/sdd of=/path/to/store/sdd.img
Dito isto, parece que os dados armazenados nessas coisas são surpreendentemente resistentes a ressincronizações rebeldes. Continue lendo, há esperança, e este pode ser o dia em que atingi o limite de respostas.
O melhor cenário
Criei uma VM para recriar seu cenário. As unidades têm apenas 100 MB, então eu não esperaria uma eternidade em cada ressincronização, mas, caso contrário, essa seria uma representação bastante precisa.
Construiu o array da maneira mais genérica e padrão possível - blocos de 512k, layout simétrico à esquerda, discos em ordem alfabética. Nada de especial.
root@test:~# mdadm --create /dev/md0 --chunk=512 --level=5 --raid-devices=3 /dev/sdb1 /dev/sdc1 /dev/sdd1
mdadm: Defaulting to version 1.2 metadata
mdadm: array /dev/md0 started.
root@test:~# cat /proc/mdstat
Personalities : [linear] [multipath] [raid0] [raid1] [raid6] [raid5] [raid4] [raid10]
md0 : active raid5 sdd1[3] sdc1[1] sdb1[0]
203776 blocks super 1.2 level 5, 512k chunk, algorithm 2 [3/3] [UUU]
unused devices: <none>
Por enquanto, tudo bem; vamos criar um sistema de arquivos e colocar alguns dados nele.
root@test:~# mkfs.ext4 /dev/md0
mke2fs 1.41.14 (22-Dec-2010)
Filesystem label=
OS type: Linux
Block size=1024 (log=0)
Fragment size=1024 (log=0)
Stride=512 blocks, Stripe width=1024 blocks
51000 inodes, 203776 blocks
10188 blocks (5.00%) reserved for the super user
First data block=1
Maximum filesystem blocks=67371008
25 block groups
8192 blocks per group, 8192 fragments per group
2040 inodes per group
Superblock backups stored on blocks:
8193, 24577, 40961, 57345, 73729
Writing inode tables: done
Creating journal (4096 blocks): done
Writing superblocks and filesystem accounting information: done
This filesystem will be automatically checked every 30 mounts or
180 days, whichever comes first. Use tune2fs -c or -i to override.
root@test:~# mkdir /mnt/raid5
root@test:~# mount /dev/md0 /mnt/raid5
root@test:~# echo "data" > /mnt/raid5/datafile
root@test:~# dd if=/dev/urandom of=/mnt/raid5/randomdata count=10000
10000+0 records in
10000+0 records out
5120000 bytes (5.1 MB) copied, 0.706526 s, 7.2 MB/s
root@test:~# sha1sum /mnt/raid5/randomdata
847685a5d42524e5b1d5484452a649e854b59064 /mnt/raid5/randomdata
Está bem. Temos um sistema de arquivos e alguns dados ("dados" datafilee 5 MB de dados aleatórios com esse hash SHA1 randomdata) nele; vamos ver o que acontece quando fazemos uma recriação.
root@test:~# umount /mnt/raid5
root@test:~# mdadm --stop /dev/md0
mdadm: stopped /dev/md0
root@test:~# cat /proc/mdstat
Personalities : [linear] [multipath] [raid0] [raid1] [raid6] [raid5] [raid4] [raid10]
unused devices: <none>
root@test:~# mdadm --create /dev/md1 --chunk=512 --level=5 --raid-devices=3 /dev/sdb1 /dev/sdc1 /dev/sdd1
mdadm: /dev/sdb1 appears to be part of a raid array:
level=raid5 devices=3 ctime=Sat Jan 7 21:07:06 2012
mdadm: /dev/sdc1 appears to be part of a raid array:
level=raid5 devices=3 ctime=Sat Jan 7 21:07:06 2012
mdadm: /dev/sdd1 appears to be part of a raid array:
level=raid5 devices=3 ctime=Sat Jan 7 21:07:06 2012
Continue creating array? y
mdadm: Defaulting to version 1.2 metadata
mdadm: array /dev/md1 started.
root@test:~# cat /proc/mdstat
Personalities : [linear] [multipath] [raid0] [raid1] [raid6] [raid5] [raid4] [raid10]
md1 : active raid5 sdd1[2] sdc1[1] sdb1[0]
203776 blocks super 1.2 level 5, 512k chunk, algorithm 2 [3/3] [UUU]
unused devices: <none>
A ressincronização terminou muito rapidamente com esses pequenos discos, mas ocorreu. Então aqui está o que estava me incomodando antes; sua fdisk -lsaída. Não ter um quadro de partição no mddispositivo não é um problema, é esperado. Seu sistema de arquivos reside diretamente no dispositivo de bloco falso, sem tabela de partição.
root@test:~# fdisk -l
...
Disk /dev/md1: 208 MB, 208666624 bytes
2 heads, 4 sectors/track, 50944 cylinders, total 407552 sectors
Units = sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 524288 bytes / 1048576 bytes
Disk identifier: 0x00000000
Disk /dev/md1 doesn't contain a valid partition table
Sim, sem mesa de partição. Mas...
root@test:~# fsck.ext4 /dev/md1
e2fsck 1.41.14 (22-Dec-2010)
/dev/md1: clean, 12/51000 files, 12085/203776 blocks
Sistema de arquivos perfeitamente válido, após uma ressincronização. Então isso é bom; vamos verificar nossos arquivos de dados:
root@test:~# mount /dev/md1 /mnt/raid5/
root@test:~# cat /mnt/raid5/datafile
data
root@test:~# sha1sum /mnt/raid5/randomdata
847685a5d42524e5b1d5484452a649e854b59064 /mnt/raid5/randomdata
Sólido - sem corrupção de dados! Mas isso é exatamente com as mesmas configurações, então nada foi mapeado de maneira diferente entre os dois grupos RAID. Vamos deixar isso de lado antes que tentemos quebrá-lo.
root@test:~# umount /mnt/raid5
root@test:~# mdadm --stop /dev/md1
Dando um passo atrás
Antes de tentarmos resolver isso, vamos falar sobre por que é difícil quebrar. O RAID 5 funciona usando um bloco de paridade que protege uma área do mesmo tamanho que o bloco em todos os outros discos da matriz. A paridade não está apenas em um disco específico, é girada em torno dos discos uniformemente para distribuir melhor a carga de leitura nos discos em operação normal.
A operação XOR para calcular a paridade é assim:
DISK1 DISK2 DISK3 DISK4 PARITY
1 0 1 1 = 1
0 0 1 1 = 0
1 1 1 1 = 0
Portanto, a paridade é espalhada entre os discos.
DISK1 DISK2 DISK3 DISK4 DISK5
DATA DATA DATA DATA PARITY
PARITY DATA DATA DATA DATA
DATA PARITY DATA DATA DATA
Uma ressincronização geralmente é feita ao substituir um disco morto ou ausente; isso também é feito mdadm createpara garantir que os dados nos discos estejam alinhados com a aparência da geometria do RAID. Nesse caso, o último disco na especificação da matriz é aquele que é 'sincronizado' - todos os dados existentes nos outros discos são usados para a sincronização.
Portanto, todos os dados no disco 'novo' são apagados e reconstruídos; construindo novos blocos de dados a partir de blocos de paridade para o que deveria estar lá ou construindo novos blocos de paridade.
O legal é que o procedimento para essas duas coisas é exatamente o mesmo: uma operação XOR nos dados do restante dos discos. O processo de ressincronização nesse caso pode ter em seu layout que um determinado bloco deve ser um bloco de paridade e pensar que está construindo um novo bloco de paridade, quando na verdade está recriando um bloco de dados antigo. Portanto, mesmo que pense que está construindo isso:
DISK1 DISK2 DISK3 DISK4 DISK5
PARITY DATA DATA DATA DATA
DATA PARITY DATA DATA DATA
DATA DATA PARITY DATA DATA
... pode ser apenas reconstruindo a DISK5partir do layout acima.
Portanto, é possível que os dados permaneçam consistentes, mesmo que a matriz tenha sido construída incorretamente.
Jogando um macaco nas obras
(não uma chave inglesa; o macaco inteiro)
Teste 1:
Vamos fazer a matriz na ordem errada! sdcentão sddentão sdb..
root@test:~# mdadm --create /dev/md1 --chunk=512 --level=5 --raid-devices=3 /dev/sdc1 /dev/sdd1 /dev/sdb1
mdadm: /dev/sdc1 appears to be part of a raid array:
level=raid5 devices=3 ctime=Sat Jan 7 23:06:34 2012
mdadm: /dev/sdd1 appears to be part of a raid array:
level=raid5 devices=3 ctime=Sat Jan 7 23:06:34 2012
mdadm: /dev/sdb1 appears to be part of a raid array:
level=raid5 devices=3 ctime=Sat Jan 7 23:06:34 2012
Continue creating array? y
mdadm: Defaulting to version 1.2 metadata
mdadm: array /dev/md1 started.
root@test:~# cat /proc/mdstat
Personalities : [linear] [multipath] [raid0] [raid1] [raid6] [raid5] [raid4] [raid10]
md1 : active raid5 sdb1[3] sdd1[1] sdc1[0]
203776 blocks super 1.2 level 5, 512k chunk, algorithm 2 [3/3] [UUU]
unused devices: <none>
Ok, está tudo bem. Nós temos um sistema de arquivos?
root@test:~# fsck.ext4 /dev/md1
e2fsck 1.41.14 (22-Dec-2010)
fsck.ext4: Superblock invalid, trying backup blocks...
fsck.ext4: Bad magic number in super-block while trying to open /dev/md1
The superblock could not be read or does not describe a correct ext2
filesystem. If the device is valid and it really contains an ext2
filesystem (and not swap or ufs or something else), then the superblock
is corrupt, and you might try running e2fsck with an alternate superblock:
e2fsck -b 8193 <device>
Não! Por que é que? Porque enquanto os dados estão todos lá, estão na ordem errada; o que antes era 512KB de A, depois 512KB de B, A, B e assim por diante, agora foi embaralhado para B, A, B, A. O disco agora parece uma bobagem no verificador do sistema de arquivos, não será executado. A saída de mdadm --misc -D /dev/md1nos dá mais detalhes; Se parece com isso:
Number Major Minor RaidDevice State
0 8 33 0 active sync /dev/sdc1
1 8 49 1 active sync /dev/sdd1
3 8 17 2 active sync /dev/sdb1
Quando deve ficar assim:
Number Major Minor RaidDevice State
0 8 17 0 active sync /dev/sdb1
1 8 33 1 active sync /dev/sdc1
3 8 49 2 active sync /dev/sdd1
Então, está tudo muito bem. Substituímos um monte de blocos de dados por novos blocos de paridade neste período. Recrie, com a ordem correta agora:
root@test:~# mdadm --stop /dev/md1
mdadm: stopped /dev/md1
root@test:~# mdadm --create /dev/md1 --chunk=512 --level=5 --raid-devices=3 /dev/sdb1 /dev/sdc1 /dev/sdd1
mdadm: /dev/sdb1 appears to be part of a raid array:
level=raid5 devices=3 ctime=Sat Jan 7 23:11:08 2012
mdadm: /dev/sdc1 appears to be part of a raid array:
level=raid5 devices=3 ctime=Sat Jan 7 23:11:08 2012
mdadm: /dev/sdd1 appears to be part of a raid array:
level=raid5 devices=3 ctime=Sat Jan 7 23:11:08 2012
Continue creating array? y
mdadm: Defaulting to version 1.2 metadata
mdadm: array /dev/md1 started.
root@test:~# fsck.ext4 /dev/md1
e2fsck 1.41.14 (22-Dec-2010)
/dev/md1: clean, 12/51000 files, 12085/203776 blocks
Legal, ainda existe um sistema de arquivos lá! Ainda tem dados?
root@test:~# mount /dev/md1 /mnt/raid5/
root@test:~# cat /mnt/raid5/datafile
data
root@test:~# sha1sum /mnt/raid5/randomdata
847685a5d42524e5b1d5484452a649e854b59064 /mnt/raid5/randomdata
Sucesso!
Teste 2
Ok, vamos mudar o tamanho do pedaço e ver se isso nos deixa quebrados.
root@test:~# umount /mnt/raid5
root@test:~# mdadm --stop /dev/md1
mdadm: stopped /dev/md1
root@test:~# mdadm --create /dev/md1 --chunk=64 --level=5 --raid-devices=3 /dev/sdb1 /dev/sdc1 /dev/sdd1
mdadm: /dev/sdb1 appears to be part of a raid array:
level=raid5 devices=3 ctime=Sat Jan 7 23:21:19 2012
mdadm: /dev/sdc1 appears to be part of a raid array:
level=raid5 devices=3 ctime=Sat Jan 7 23:21:19 2012
mdadm: /dev/sdd1 appears to be part of a raid array:
level=raid5 devices=3 ctime=Sat Jan 7 23:21:19 2012
Continue creating array? y
mdadm: Defaulting to version 1.2 metadata
mdadm: array /dev/md1 started.
root@test:~# fsck.ext4 /dev/md1
e2fsck 1.41.14 (22-Dec-2010)
fsck.ext4: Superblock invalid, trying backup blocks...
fsck.ext4: Bad magic number in super-block while trying to open /dev/md1
The superblock could not be read or does not describe a correct ext2
filesystem. If the device is valid and it really contains an ext2
filesystem (and not swap or ufs or something else), then the superblock
is corrupt, and you might try running e2fsck with an alternate superblock:
e2fsck -b 8193 <device>
Sim, sim, é mangueira quando configurada assim. Mas podemos nos recuperar?
root@test:~# mdadm --stop /dev/md1
mdadm: stopped /dev/md1
root@test:~# mdadm --create /dev/md1 --chunk=512 --level=5 --raid-devices=3 /dev/sdb1 /dev/sdc1 /dev/sdd1
mdadm: /dev/sdb1 appears to be part of a raid array:
level=raid5 devices=3 ctime=Sat Jan 7 23:21:51 2012
mdadm: /dev/sdc1 appears to be part of a raid array:
level=raid5 devices=3 ctime=Sat Jan 7 23:21:51 2012
mdadm: /dev/sdd1 appears to be part of a raid array:
level=raid5 devices=3 ctime=Sat Jan 7 23:21:51 2012
Continue creating array? y
mdadm: Defaulting to version 1.2 metadata
mdadm: array /dev/md1 started.
root@test:~# fsck.ext4 /dev/md1
e2fsck 1.41.14 (22-Dec-2010)
/dev/md1: clean, 12/51000 files, 12085/203776 blocks
root@test:~# mount /dev/md1 /mnt/raid5/
root@test:~# cat /mnt/raid5/datafile
data
root@test:~# sha1sum /mnt/raid5/randomdata
847685a5d42524e5b1d5484452a649e854b59064 /mnt/raid5/randomdata
Sucesso de novo!
Teste 3
Este é o que eu pensei que mataria dados com certeza - vamos fazer um algoritmo de layout diferente!
root@test:~# umount /mnt/raid5
root@test:~# mdadm --stop /dev/md1
mdadm: stopped /dev/md1
root@test:~# mdadm --create /dev/md1 --chunk=512 --level=5 --layout=right-asymmetric --raid-devices=3 /dev/sdb1 /dev/sdc1 /dev/sdd1
mdadm: /dev/sdb1 appears to be part of a raid array:
level=raid5 devices=3 ctime=Sat Jan 7 23:32:34 2012
mdadm: /dev/sdc1 appears to be part of a raid array:
level=raid5 devices=3 ctime=Sat Jan 7 23:32:34 2012
mdadm: /dev/sdd1 appears to be part of a raid array:
level=raid5 devices=3 ctime=Sat Jan 7 23:32:34 2012
Continue creating array? y
mdadm: Defaulting to version 1.2 metadata
mdadm: array /dev/md1 started.
root@test:~# cat /proc/mdstat
Personalities : [linear] [multipath] [raid0] [raid1] [raid6] [raid5] [raid4] [raid10]
md1 : active raid5 sdd1[3] sdc1[1] sdb1[0]
203776 blocks super 1.2 level 5, 512k chunk, algorithm 1 [3/3] [UUU]
unused devices: <none>
root@test:~# fsck.ext4 /dev/md1
e2fsck 1.41.14 (22-Dec-2010)
fsck.ext4: Superblock invalid, trying backup blocks...
Superblock has an invalid journal (inode 8).
Assustador e ruim - ele acha que encontrou algo e quer fazer alguma correção! Ctrl+ C!
Clear<y>? cancelled!
fsck.ext4: Illegal inode number while checking ext3 journal for /dev/md1
Ok, crise evitada. Vamos ver se os dados ainda estão intactos após ressincronizar com o layout errado:
root@test:~# mdadm --stop /dev/md1
mdadm: stopped /dev/md1
root@test:~# mdadm --create /dev/md1 --chunk=512 --level=5 --raid-devices=3 /dev/sdb1 /dev/sdc1 /dev/sdd1
mdadm: /dev/sdb1 appears to be part of a raid array:
level=raid5 devices=3 ctime=Sat Jan 7 23:33:02 2012
mdadm: /dev/sdc1 appears to be part of a raid array:
level=raid5 devices=3 ctime=Sat Jan 7 23:33:02 2012
mdadm: /dev/sdd1 appears to be part of a raid array:
level=raid5 devices=3 ctime=Sat Jan 7 23:33:02 2012
Continue creating array? y
mdadm: Defaulting to version 1.2 metadata
mdadm: array /dev/md1 started.
root@test:~# fsck.ext4 /dev/md1
e2fsck 1.41.14 (22-Dec-2010)
/dev/md1: clean, 12/51000 files, 12085/203776 blocks
root@test:~# mount /dev/md1 /mnt/raid5/
root@test:~# cat /mnt/raid5/datafile
data
root@test:~# sha1sum /mnt/raid5/randomdata
847685a5d42524e5b1d5484452a649e854b59064 /mnt/raid5/randomdata
Sucesso!
Teste 4
Vamos também provar que o zeramento do superbloco não é prejudicial rapidamente:
root@test:~# umount /mnt/raid5
root@test:~# mdadm --stop /dev/md1
mdadm: stopped /dev/md1
root@test:~# mdadm --misc --zero-superblock /dev/sdb1 /dev/sdc1 /dev/sdd1
root@test:~# mdadm --create /dev/md1 --chunk=512 --level=5 --raid-devices=3 /dev/sdb1 /dev/sdc1 /dev/sdd1
mdadm: Defaulting to version 1.2 metadata
mdadm: array /dev/md1 started.
root@test:~# fsck.ext4 /dev/md1
e2fsck 1.41.14 (22-Dec-2010)
/dev/md1: clean, 12/51000 files, 12085/203776 blocks
root@test:~# mount /dev/md1 /mnt/raid5/
root@test:~# cat /mnt/raid5/datafile
data
root@test:~# sha1sum /mnt/raid5/randomdata
847685a5d42524e5b1d5484452a649e854b59064 /mnt/raid5/randomdata
Sim, não é grande coisa.
Teste 5
Vamos jogar tudo o que temos nele. Todos os 4 testes anteriores, combinados.
- Ordem incorreta do dispositivo
- Tamanho errado do pedaço
- Algoritmo de layout errado
- Superblocos zerados (faremos isso entre as duas criações)
Avante!
root@test:~# umount /mnt/raid5
root@test:~# mdadm --stop /dev/md1
mdadm: stopped /dev/md1
root@test:~# mdadm --misc --zero-superblock /dev/sdb1 /dev/sdc1 /dev/sdd1
root@test:~# mdadm --create /dev/md1 --chunk=64 --level=5 --raid-devices=3 --layout=right-symmetric /dev/sdc1 /dev/sdd1 /dev/sdb1
mdadm: Defaulting to version 1.2 metadata
mdadm: array /dev/md1 started.
root@test:~# cat /proc/mdstat
Personalities : [linear] [multipath] [raid0] [raid1] [raid6] [raid5] [raid4] [raid10]
md1 : active raid5 sdb1[3] sdd1[1] sdc1[0]
204672 blocks super 1.2 level 5, 64k chunk, algorithm 3 [3/3] [UUU]
unused devices: <none>
root@test:~# fsck.ext4 /dev/md1
e2fsck 1.41.14 (22-Dec-2010)
fsck.ext4: Superblock invalid, trying backup blocks...
fsck.ext4: Bad magic number in super-block while trying to open /dev/md1
The superblock could not be read or does not describe a correct ext2
filesystem. If the device is valid and it really contains an ext2
filesystem (and not swap or ufs or something else), then the superblock
is corrupt, and you might try running e2fsck with an alternate superblock:
e2fsck -b 8193 <device>
root@test:~# mdadm --stop /dev/md1
mdadm: stopped /dev/md1
O veredito?
root@test:~# mdadm --misc --zero-superblock /dev/sdb1 /dev/sdc1 /dev/sdd1
root@test:~# mdadm --create /dev/md1 --chunk=512 --level=5 --raid-devices=3 /dev/sdb1 /dev/sdc1 /dev/sdd1
mdadm: Defaulting to version 1.2 metadata
mdadm: array /dev/md1 started.
root@test:~# cat /proc/mdstat
Personalities : [linear] [multipath] [raid0] [raid1] [raid6] [raid5] [raid4] [raid10]
md1 : active raid5 sdd1[3] sdc1[1] sdb1[0]
203776 blocks super 1.2 level 5, 512k chunk, algorithm 2 [3/3] [UUU]
unused devices: <none>
root@test:~# fsck.ext4 /dev/md1
e2fsck 1.41.14 (22-Dec-2010)
/dev/md1: clean, 13/51000 files, 17085/203776 blocks
root@test:~# mount /dev/md1 /mnt/raid5/
root@test:~# cat /mnt/raid5/datafile
data
root@test:~# sha1sum /mnt/raid5/randomdata
847685a5d42524e5b1d5484452a649e854b59064 /mnt/raid5/randomdata
Uau.
Portanto, parece que nenhuma dessas ações corrompeu os dados de forma alguma. Fiquei bastante surpreso com esse resultado, francamente; Eu esperava chances moderadas de perda de dados na alteração do tamanho do bloco e alguma perda definitiva na alteração do layout. Eu aprendi algo hoje.
Então .. Como obtenho meus dados?
O máximo de informações que você tiver sobre o sistema antigo seria extremamente útil para você. Se você conhece o tipo de sistema de arquivos, se possui alguma cópia antiga /proc/mdstatcom informações sobre a ordem da unidade, algoritmo, tamanho do pedaço e versão dos metadados. Você tem os alertas de email do mdadm configurados? Se sim, encontre um antigo; caso contrário, verifique /var/spool/mail/root. Verifique ~/.bash_historyse a sua compilação original está lá.
Então, a lista de coisas que você deve fazer:
- Faça backup dos discos
ddantes de fazer qualquer coisa !!
- Tente
fscko md ativo e atual - você pode ter acabado de construir na mesma ordem de antes. Se você conhece o tipo de sistema de arquivos, isso é útil; use essa fsckferramenta específica . Se alguma das ferramentas oferecer alguma correção, não deixe, a menos que tenha certeza de que eles realmente encontraram o sistema de arquivos válido! Se uma fsckoferta for consertar algo para você, não hesite em deixar um comentário para perguntar se isso realmente está ajudando ou está prestes a destruir dados.
- Tente criar a matriz com parâmetros diferentes. Se você tem um antigo
/proc/mdstat, pode apenas imitar o que ele mostra; caso contrário, você estará no escuro - tentar todas as diferentes ordens de unidade é razoável, mas verificar todos os tamanhos de bloco possíveis com todas as ordens possíveis é inútil. Para cada um, fscké preciso ver se você tem algo promissor.
Então é isso. Desculpe o romance, fique à vontade para deixar um comentário, se tiver alguma dúvida, e boa sorte!
nota de rodapé: menos de 22 mil caracteres; 8k + tímido do limite de comprimento