Файл, скопированный по сети, отличается от оригинала

Question

Переместив довольно большой объем данных (~ 1 ТБ) по сети из одного хранилища в другое, я заметил, что файл в целевой системе отличается от исходного.

Настройка: ПК (Windows 7 64) с Windows Sharing -> 1000BaseT сетевой коммутатор 2x 1G -> ПК (Windows XP) в качестве клиента Windows Sharing или NAS с Windows Sharing (возможно, Samba?) -> 1000BaseT сетевой коммутатор 1x 1G -> ПК (Windows 7 64) в качестве клиента общего доступа Windows

Процедура: Скопировать из общего ресурса с Total Commander - об ошибке не сообщается -> Синхронизировать каталоги в Total Commander (сравнить по содержимому) - некоторые файлы отличаются -> Разница Total Commander (двойной щелчок в выводе Синхронизировать каталоги) - некоторые файлы, отмеченные как разные, отображаются разница, некоторые из них, как сообщается, на этот раз одинаковы. Я пробовал ПК-ПК и ПК-NAS, и оба одинаковы.

Я проверил один из файлов (~ 60 ГБ один), и кажется, что различия всегда являются однобайтовыми со значением 0 на оригинале и 128 на цели. Они случайным образом распределяются по всему файлу, около 10 из них. Повторный запуск diff показывает, что некоторые из них сохраняются, а некоторые изменяются, но их примерно столько же.

РЕДАКТИРОВАТЬ: Чтобы ответить на подозрение syneticon-dj о TC, я должен отметить, что я написал простое приложение на C #, которое читает два файла с использованием .NET API и сравнивает их побайтно. Вот как я получил информацию о разнице в предыдущем абзаце.

Кажется, что передача по сети терпит неудачу один бит каждые 6 гигабайт или около того. Как это возможно? Это нормальное поведение? Почему он проходит контрольные суммы на уровне TCP? Как я могу сказать, что не так и что следует заменить?

РЕДАКТИРОВАТЬ: Если передача по сети вряд ли является причиной ошибок, что может быть реальной причиной?

Answer 1

Я предпочел бы заподозрить ошибку в функции TC "сравнивать по содержимому" и перепроверить, используя локальную контрольную сумму для файлов с обеих сторон, используя что-то вроде хэшей MD5 или SHA-1 и сравнивая контрольные суммы визуально.

Некоторые рассуждения

Кадр Ethernet имеет контрольную сумму CRC 32 бита на кадр. TCP добавляет 16-битную контрольную сумму CRC. Неисправный пакет с ошибкой в один бит, прошедший обе контрольные суммы, будет менее вероятным, чем для одной 32-битной проверки CRC (2 ^ -32), но более вероятным, чем произведение обеих вероятностей (2 ^ -16 * 2 ^ - 32 = 2 ^ -48). Где именно, зависит от характеристик алгоритмов.

Предполагая размер полезной нагрузки в 1,400 байт (то есть, если вы не используете Jumbo Frames) и округляя его до 2048 байт для более простых вычислений, это примерно означало бы ошибку каждые 2 ^ 42 до 2 ^ 58 байт (от 5,4 терабайт до 250 Петабайты), если каждый передаваемый кадр содержит однобайтовую ошибку.

Это, однако, наверняка будет замечено в противном случае - частота сбоев контрольной суммы CRC, которая настолько высока, что фактически погасит ваши передачи Ethernet - вы получите крайне низкие скорости передачи для вашей копии файла. И вы сможете увидеть множество сбоев проверки CRC в счетчиках портов RMON ваших управляемых коммутаторов.

Таким образом, учитывая природу вашей ошибки, весьма маловероятно, что это ошибка передачи - они также выглядят значительно более случайными.

Answer 2

Я подозревал бы плохую память на любой из машин. Пожалуйста, запустите memtest86 на обоих из них.

Answer 3

Контрольная сумма IP - это 16-битный CRC. Вы можете ожидать, что примерно 1 из 65k поврежденных пакетов проскользнет. Если вы выполняете передачу больших файлов, вам, вероятно, лучше использовать выделенный копировщик файлов, использующий криптографические контрольные суммы на меньших блоках. Как, скажем, запуск MD5 и SHA1 через чанки размером 1 Мб, повторная передача чанка, если одна или обе контрольные суммы различаются.

Предложенный размер порции (1 МБ) - это более интуитивное чувство, чем определено в случае сплошной инженерии, если вы видите ошибку примерно каждые 6 ГБ, это приведет к общему увеличению трафика примерно на 0,1%.