Um problema estranho está relacionado ao ext4 / lvm / raid-5 após a recuperação da partição

Question

Eu tenho 3 discos rígidos, nos seguintes parágrafos chamados / dev / sda, / dev / sdb e / dev / sdc, o mais novo veio primeiro. Nota: / dev / sdc tem uma partição primária / dev / sdc1, uma partição estendida / dev / sd2 e 3 partições lógicas / dev / sdc5, / dev / sdc6 e / dev / sda7.

Eu criei um dispositivo RAID 5 degradado / dev / md0 com / dev / sda5 e / dev / sdb5 (planejado para adicionar / dev / sdc5 ao RAID para transformá-lo em estado normal), então usei / dev / md0 como o único pv do LVM, e criei um lv com o sistema de arquivos ext4 / dev / mapper / vg0-lv0.

Infelizmente, ao explorar e jogar com o LVM, executei dd if=/dev/zero of=/dev/sdc1 bs=64M count=10 após excluir / dev / sdc1. Então, na verdade, os zeros foram gravados em / dev / sdc2 e parte quebrada da tabela de partições armazenada em / dev / sdc2 e a parte inicial de / dev / sdc5.

Quando percebi isso, imediatamente fiz uma imagem de / dev / sdc via dd assim: dd if=/dev/sdc of=/mount-point-of-vg0-lv0/sdc.img .

Vários dias depois, finalmente tenho tempo de tentar recuperar os dados em / dev / sdc, na verdade, apenas / dev / sdc7, já que é a única partição sem backup. Eu corri testdisk com o arquivo de imagem sdc.img, usei o recurso Quick Search para reconstruir a tabela de partições, perdendo-a para / dev / loop0. / dev / loop0p7 (que é a imagem de / dev / sdc7) estava de volta e montável, e todos os arquivos parecem OK. Em seguida, executei find /mount-point-of-loop0p7 -type f -exec md5sum {} \; > sdc7_img.md5sum para criar a lista de soma de verificação MD5 para todos os arquivos em / dev / loop0p7.

Ao lidar com o dispositivo físico / dev / sdc, a Pesquisa rápida do testdisk não encontra todas as partições, a Pesquisa profunda sim. Então eu montei a lista de soma de verificação MD5 sdc7.md5sum para todos os arquivos em / dev / sdc7 físicos com comando similar. Quando comparado com sdc7_image.md5sum, encontrei 4 arquivos diferentes. Depois de compará-los manualmente, notei que cada arquivo tem apenas uma diferença de 1 byte. E como um arquivo tem CRC32 em seu nome, posso confirmar se o arquivo / dev / sdc7 está correto.

Então, minha pergunta é: por que essa coisa estranha aconteceu? Eu já corri fsck.ext4 -c -c /dev/mapper/vg0-lv0 para confirmar que não tem blocos ruins. Diferenças de 4 bytes em dados de 1,2 TB estão em uma porcentagem tão pequena, mas isso me faz não ter confiança em armazenar dados em / dev / mapper / vg0-lv0 no futuro.

Atualização: Eu tenho que mencionar, todas as operações foram feitas no mais recente ArchLinux rodando no VirtualBox 4.1.16, que rodando no Windows 7. / dev / sda, / dev / sdb e / dev / sdc estão todos ligados com o físico discos rígidos, via VBoxManage internalcommands createrawvmdk . O VirtualBox apenas relatou o erro VERR_ACCESS_DENIED durante o md5sums feito para physical / dev / sdc7, depois de offline o disco físico via diskpart do Win7, sem mais erros.

    

Answer 1

Existem algumas coisas que poderiam ter acontecido. Primeiro, você não mencionou a desmontagem do sdc7 antes de criar a imagem do disco, então pode ser que os dados estivessem sendo gravados no momento. Eu vou adivinhar que esse não era o caso, ou você não estaria perguntando. Eu não posso culpar sua reação de "primeira coisa, imagem do disco", que é uma reação muito boa. Embora eu note que antes de você reiniciar, o kernel ainda tinha a tabela de partições na memória, confira /proc/partitions .

A primeira coisa a verificar é sobre erros de memória. Você poderia ter RAM ruim. Seus dados, sem dúvida, passaram pela RAM várias vezes. Eu estou supondo que você não tem memória ECC, o que provavelmente pegaria isso.

Os discos rígidos também apresentam erros. Procurando uma folha de especificações para alguns discos rígidos de consumo aleatórios, eles dizem 1 por 100 Tbit. Você copiou 1.2TB pelo menos algumas vezes (leia da fonte, leia do destino), de modo que é algo como 19 Tbit ler. Ter um pequeno erro é crível. (Eles não dão uma taxa de erro para gravações nas folhas de especificações, infelizmente).

Houve alguma rima ou razão por trás das corrupções de byte único? cmp -l pode informar os bytes que variam. Por exemplo, se fosse sempre o mesmo deslocamento em uma página (o tamanho de sua página provavelmente é 4K) e sempre o mesmo bit, isso indicaria quase de forma conclusiva a RAM defeituosa. Mesmo que seja sempre apenas o mesmo bit, ou o mesmo offset, isso seria bastante conclusivo (E você tinha o CRC32 para todos os quatro arquivos, ou apenas um?)