Md5sums incorretos nos arquivos baixados

Question

Eu tenho um servidor linux Ubuntu 10.04.1 LTS que está tendo alguns problemas estranhos ... Eu apenas tentei fazer o download de um arquivo de 440 MB tgz sobre HTTP usando o wget, e ao expandi-lo com tar -xzf filename.tgz recebi:

gzip: stdin: invalid compressed data--crc error

Encontrando este estranho eu renomei o arquivo filename-bad.tgz e baixei novamente. Recebi o mesmo erro no segundo download ... O site listou uma soma de verificação md5 para o arquivo, então eu verifiquei as duas tentativas de download para ver se talvez esse arquivo estava corrompido ...

Os dois arquivos tinham checksums diferentes!

Então baixei esse arquivo para minha estação de trabalho local e executei md5sum nele. Desta vez, a soma de verificação MD5 estava correta e o arquivo foi extraído corretamente. Então copiei o arquivo da minha estação de trabalho para o servidor e executei md5sum nessa cópia. Era um novo md5sum, diferente do md5sum correto e diferente das outras duas tentativas!

Aqui está o detalhe do servidor:

• CPU Intel (R) Core (TM) i5 (Dual Core)
• 8 GB de RAM
• Matriz RAID5 de software usando dispositivos linux md e 3 unidades SATA de 1TB
• 2 placas ethernet, conectadas a duas redes diferentes em nosso escritório (a rede cabeada e sem fio)

Suspeitei que talvez a matriz RAID estivesse degradada / funcionando incorretamente, então corri mdadm --detail e ela relatou que o estado era clean e todas as unidades estavam em active sync . Para testar ainda mais, copiei um arquivo de 1GB de um cartão SD para o array RAID, e o md5sum desse arquivo foi verificado.

O que poderia estar acontecendo?

EDIT: Saída de cmp -l conforme solicitado:

324268145 115 105
324268657 274 264
324269297 332 322
324270577 345 344
324270833 155 154

EDIT2 : Eu acabei de perceber que uma das cópias realmente tem a soma de verificação MD5 correta, então copiei o arquivo da minha máquina local mais duas vezes e ambas as vezes a soma de verificação estava correta! Então, mais alguns testes estão em ordem aqui ...

EDIT3 : não consigo reproduzir este problema. Que soa como RAM ruim para mim. Vai rodar o memtest hoje à noite, qualquer outra idéia bem-vinda!

EDIT4 : ok. Agora isso é estranho. O problema é 100% reproduzível quando a cópia do arquivo para uma máquina virtual VMWare específica está sendo executada no servidor. Se eu copiar o arquivo para essa máquina virtual, às vezes, se eu copiar imediatamente o arquivo para o host, o problema será reproduzível. scp também diz isso ao copiar para a máquina virtual:

Received disconnect from 10.1.0.73: 2: Packet corrupt

Todos estes parecem ser indícios de má RAM. Todos concordam? Alguma outra explicação possível?

EDIT5: resolvido . Nossa, o que diabos poderia estar causando esse problema? Eu simplesmente não entendo ....: -)

(Eu testei a memória RAM nesse sistema logo depois que comprei, o que foi há dois ou três meses atrás ... oh bem. Parece que é hora de ligar para a Dell ...)

    

Answer 1

Os dois arquivos têm o mesmo tamanho? Caso contrário, um dos arquivos provavelmente foi truncado.

Se você usou o FTP para transferir arquivos, alguns clientes assumem arquivos de texto por padrão e devem ser instruídos a entrar no modo binário ou eles irão desfazer ^M e ^J . Esta já foi uma fonte importante de arquivos corrompidos, mas é uma raridade hoje em dia.

Os pacotes TCP possuem uma soma de verificação de 16 bits. Isso significa que cerca de um erro em 65536 não será detectado, portanto, um erro de transmissão está dentro da possibilidade.

Nenhuma das possibilidades acima explica satisfatoriamente o terceiro valor de md5sum.

Tente comparar os arquivos (por exemplo, com cmp -l ) e veja se há um padrão para as diferenças. Se você ver que as diferenças sempre parecem estar em determinadas posições de bit (algo como sempre no bit mais significativo de uma posição de byte no formato 8 * n + 3), geralmente é um sinal de que sua RAM está com defeito. Geralmente, em caso de corrupção de dados não explicável por transmissão de software ou de rede, a RAM é o primeiro local a procurar.

    

Answer 2

Se você estiver transferindo usando FTP, use a transferência de modo binário. Caso contrário, quaisquer terminações de linha no arquivo serão desconfiguradas. O Windows não precisa manipular os terminadores de linha no modo de texto.

    

Answer 3

Como uma verificação rápida, se você transferir o arquivo usando sneakernet (ou seja, colocá-lo em uma unidade flash e passá-lo), ele funciona bem?