O arquivo copiado pela rede difere do original

0

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 Windows Compartilhamento - > Rede 1000BaseT 2x 1G switch - > PC (Windows XP) como cliente do Windows Sharing ou NAS com Windows Sharing (provavelmente Samba?) - > Rede 1000BaseT 1x 1G switch - > PC (Windows 7 64) como cliente do Windows Sharing

Procedimento: Copiar de compartilhamento com o Total Commander - nenhum erro relatado - > Sincronizar dirs em Total Commanded (comparar por conteúdo) - alguns arquivos são diferentes - > Total Diff do Comandante (clique duas vezes na saída Sincronizar dirs) - alguns arquivos marcados como diferentes mostram diferença, 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 de byte único 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 persistindo 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 notar 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?

    
por Jan Svab 18.12.2011 / 09:04

3 respostas

3

Prefiro 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 MD5 ou SHA-1 hashes 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 que o produto de ambas as probabilidades (2 ^ -16 * 2 ^ - 32 = 2 ^ -48). Onde exatamente, depende das características dos algoritmos.

Assumindo 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 para 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 - esses também pareceriam consideravelmente mais aleatórios.

    
por 18.12.2011 / 15:26
2

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

    
por 18.12.2011 / 18:49
0

A soma de verificação de IP é um CRC de 16 bits. Você pode esperar que cerca de 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. Por exemplo, executando 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%.

    
por 18.12.2011 / 13:12