Файл, скопійований через мережу, відрізняється від оригіналу

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

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

Порядок дії: Скопіюйте з загального доступу до Total Commander - помилки не повідомляється -> Синхронізувати дріфи в Total Commanded (порівняйте за вмістом) - деякі файли відрізняються -> Total Diff Differ (подвійне клацання у виведенні синхронізувати dirs) - деякі файли, позначені як різні, показують різниця, деякі з них цього разу повідомляються як такі ж. Я спробував PC-PC та PC-NAS, і те саме.

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

EDIT: Щоб відповісти на підозру Syneticon-dj щодо TC, я маю зазначити, що я написав просту програму C #, яка читає два файли за допомогою .NET API та порівнює їх байт за байтами. Ось як я отримав інформацію про різниці в попередньому абзаці.

Здається, мережева передача провалюється один біт кожні 6 гігабайт або близько того. Як це можливо? Це нормальна поведінка? Як це передає контрольні суми на рівні TCP? Як я можу сказати, що не так і що слід замінити?

EDIT: Якщо передача мережі навряд чи є причиною помилок, що може бути реальною причиною?

Я скоріше запідозрив б помилку в ТС "порівняти за вмістом" та подвійно перевірити, використовуючи локальну генерацію контрольної суми для файлів обох сторін, використовуючи щось на зразок хешів MD5 або SHA-1 і візуально порівнюючи контрольні суми.

Деякі міркування

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

Якщо припустити розмір корисного навантаження в 1400 байт (тобто якщо ви не використовуєте рамки Jumbo) і округлення його до 2048 байт для більш легких обчислень, це грубо означатиме помилку кожні 2 ^ 42 до 2 ^ 58 байт (5,4 Терабайт до 250 Петабайти), якщо кожен переданий кадр має однобайтову помилку .

Однак це, безумовно, буде помічено інакше - частота відмов контрольної суми CRC, яка настільки висока, фактично вгамує ваші передачі Ethernet, - ви отримаєте бездоганно низькі швидкості передачі для копії файлу. І ви зможете побачити безліч помилок перевірки CRC у лічильниках портів керованих комутаторів RMON.

Отже, враховуючи характер вашої помилки, здається, малоймовірно, що це помилка передачі - вони також виглядатимуть значно більш випадковими.

Я б підозрював погану пам'ять на будь-якій з машин. Будь ласка, запустіть memtest86 на обох.

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

Запропонований розмір шматка (1 Мб) більше відчуває кишки, ніж визначається твердою технікою, якщо ви бачите помилку приблизно кожні 6 Гб, це призведе до загального збільшення трафіку приблизно на 0,1%.