Corrupção de arquivos (checksums incorretos) em arquivos grandes copiados para o guest do VMware

Question

Na criação de um laboratório de desenvolvimento, eu tenho um sistema de desktop rodando o ESXi 4.1.0 (licença livre) no SATA RAID 0 (já adquirido e configurado quando eu iniciei este trabalho; estou aberto à entrada de hardware, já que refere-se ao meu problema.) Seus convidados até o momento incluem duas VMs do Win2008 Server R2 de 64 bits e no Ubuntu 10.04 VM de 64 bits. Estou instalando nos servidores Windows.

Nós estamos copiando alguns arquivos bastante grandes (mais de um gigabyte) para uma instalação, esperando instalar mais rapidamente a partir de um disco rígido (virtual) do que da rede para o BD-ROM. O problema é que eles continuam chegando com diferentes checksums dos originais. Os tamanhos dos arquivos são os mesmos, mas o md5sum relata números diferentes (e o mesmo acontece com o instalador, já que ele se recusa a continuar quando as somas de verificação não coincidem).

Eu tentei copiar diretamente do BD-ROM (anexando a unidade do sistema operacional à unidade física do sistema host). Eu tentei copiar os arquivos grandes na máquina Windows de um colega de trabalho de sua unidade Blu-Ray; quando faço isso, as somas de verificação coincidem. Mas quando copio de sua máquina para o guest da VM em um compartilhamento de rede, as somas de verificação não correspondem mais.

Pensando que isso significava uma unidade de destino corrompida, eu a excluí no vSphere e adicionei outra unidade recém-criada. O problema persiste. Não tenho certeza do que tentar em seguida.

    

Answer 1

Portanto, esta foi uma combinação de uma má distribuição de RAM e um bug no kernel do Linux que afeta o SATA. Eu coloquei o Ubuntu 10.04 lá e, eventualmente, deixei o memtest86 + rodando a noite toda (como executá-lo por 1.5 passagens antes de não ter eliminado o problema).

Depois que removi a RAM ruim, comecei a ver erros SATA em / var / syslog, semelhante a este:

Dec  8 14:56:17 george kernel: [   36.442340] ata4.00: exception Emask 0x10 SAct 0x4 SErr 0x4010000 action 0xe frozen 
Dec  8 14:56:17 george kernel: [   36.442355] ata4.00: irq_stat 0x00400040, connection status changed 
Dec  8 14:56:17 george kernel: [   36.442366] ata4: SError: { PHYRdyChg DevExch } 
Dec  8 14:56:17 george kernel: [   36.442375] ata4.00: failed command: READ FPDMA QUEUED 
Dec  8 14:56:17 george kernel: [   36.442388] ata4.00: cmd 60/08:10:88:a9:87/00:00:1b:00:00/40 tag 2 ncq 4096 in 
Dec  8 14:56:17 george kernel: [   36.442389]          res 40/00:64:30:aa:8b/00:00:12:00:00/40 Emask 0x10 (ATA bus error) 
Dec  8 14:56:17 george kernel: [   36.442408] ata4.00: status: { DRDY } 
Dec  8 14:56:17 george kernel: [   36.442418] ata4: hard resetting link 
Dec  8 14:56:23 george kernel: [   41.724689] ata4: SATA link up 3.0 Gbps (SStatus 123 SControl 300) 
Dec  8 14:56:24 george kernel: [   42.445422] ata4.00: configured for UDMA/133 
Dec  8 14:56:24 george kernel: [   42.445432] ata4: EH complete

Eu finalmente descobri esse bug: link que me levou a tente um kernel Linux anterior (aquele que vem com o Ubuntu 8.04). A máquina tem funcionado bem desde então.