O arquivo copiado pela rede difere do original

Tendo movido uma grande quantidade de dados (~ 1TB) pela rede de um armazenamento para outro, notei que o arquivo no sistema de destino é diferente do original.

Configuração: PC (Windows 7 64) com o Compartilhamento do Windows - & gt; Rede 1000BaseT 2x 1G switch - & gt; PC (Windows XP) como cliente do Windows Sharing ou NAS com Windows Sharing (provavelmente Samba?) - & gt; Rede 1000BaseT 1x 1G switch - & gt; PC (Windows 7 64) como cliente do Windows Sharing

Procedimento: Copiar de compartilhamento com o Total Commander - nenhum erro relatado - & gt; Sincronizar dirs em Total Commanded (comparar por conteúdo) - alguns arquivos são diferentes - & gt; Total Diff do Comandante (clique duas vezes na saída Sincronizar dirs) - alguns arquivos marcados como diferentes mostram a diferença, e alguns deles são reportados como sendo os mesmos desta vez. Eu tentei PC-PC e PC-NAS e ambos são os mesmos.

Eu examinei um dos arquivos (~ 60GB um) e parece que as diferenças são sempre único byte com valor 0 no original e 128 no alvo. Eles estão espalhados aleatoriamente por todo o arquivo, cerca de 10 deles. Repetindo o diff mostra alguns deles persistirem e alguns deles são alterados, mas há aproximadamente a mesma quantidade deles.

EDIT: Para responder a suspeita de syneticon-dj sobre TC, eu tenho que observar que eu escrevi um aplicativo C # simples que lê dois arquivos usando o .NET API e compara-os byte por byte. Foi assim que obtive a informação do diff no parágrafo anterior.

Parece que a transferência de rede falha um bit em cada 6 gigabytes ou mais. Como isso é possível? Isso é comportamento normal? Como é que passa as somas de verificação ao nível do TCP? Como posso saber o que está errado e o que deve ser substituído?

EDIT: Se a transferência de rede é diferente de ser a causa de erros, qual poderia ser a causa real?

Eu preferiria suspeitar de um bug no recurso "comparar por conteúdo" dos TCs e verificar novamente usando a geração de soma de verificação local para os arquivos em ambos os lados usando algo como Hashes MD5 ou SHA-1 e comparando as somas de verificação visualmente.

Algum raciocínio

Um quadro Ethernet possui uma soma de verificação CRC de 32 bits por quadro. TCP adiciona uma soma de verificação CRC de 16 bits. Um pacote defeituoso com um erro de bit único passando em ambas as somas de verificação seria menos provável do que para uma única verificação CRC de 32 bits (2 ^ -32), mas mais provável do que o produto de ambas as probabilidades (2 ^ -16 * 2 ^ - 32 = 2 ^ -48). Onde exatamente, depende das características dos algoritmos.

Supondo um tamanho de carga útil de 1.400 Bytes (ou seja, se você não estiver usando Jumbo Frames) e arredondando-o para 2048 bytes para cálculos mais fáceis, significaria um erro a cada 2 ^ 42 a 2 ^ 58 Bytes (5,4 Terabytes a 250 Petabytes) se cada quadro transmitido tiver um erro de byte único .

Isso, no entanto, certamente seria notado de outra forma - uma taxa de falhas de checksum de CRC tão altas virtualmente apagaria suas transmissões de Ethernet - você obteria taxas de transferência extremamente baixas para sua cópia de arquivo. E você poderá ver muitas falhas de verificação de CRC nos contadores de portas RMON dos switches gerenciados.

Assim, dada a natureza do seu erro, parece bastante improvável que seja um erro de transmissão - estes também pareceriam consideravelmente mais aleatórios.

Eu suspeitaria de má memória em qualquer uma das máquinas. Por favor corra memtest86 em ambos.

O checksum IP é um CRC de 16 bits. Você pode esperar que aproximadamente 1 em 65k pacotes corrompidos passem. Se você está fazendo grandes transferências de arquivos, provavelmente é melhor usar uma copiadora de arquivos dedicada, usando somas de verificação criptográficas em blocos menores. Como, digamos, executar MD5 e SHA1 com mais de 1 MB, retransmitindo um pedaço se um ou ambos os checksums forem diferentes.

O tamanho do bloco sugerido (1 MB) é mais significativo do que determinado pela engenharia sólida, se você estiver vendo um erro aproximadamente a cada 6 GB, isso levaria a um aumento total no tráfego de aproximadamente 0,1%.