Неправильные md5sums в загруженных файлах

Question

У меня есть Linux-сервер Ubuntu 10.04.1 LTS, который испытывает некоторые странные проблемы ... Я просто попытался загрузить архив tgz 440 МБ по HTTP, используя wget, и при расширении его с помощью tar -xzf filename.tgz я получил:

gzip: stdin: invalid compressed data--crc error

Находя это странным, я переименовал файл filename-bad.tgz и снова загрузил его. Я получил ту же ошибку при второй загрузке ... На сайте была указана контрольная сумма md5 для файла, поэтому я проверил обе попытки загрузки, чтобы проверить, не поврежден ли этот файл ...

Два файла имели разные контрольные суммы!

Поэтому я скачал этот файл на свою локальную рабочую станцию и запустил там md5sum . На этот раз контрольная сумма MD5 была правильной, и файл извлечен правильно. Поэтому я скопировал файл со своей рабочей станции на сервер и запустил md5sum для этой копии. Это была новая md5sum, отличающаяся от правильной md5sum и отличающаяся от двух других попыток!

Вот деталь сервера:

• Процессор Intel(R) Core(TM) i5 (двухъядерный)
• 8 ГБ ОЗУ
• Программный массив RAID5 с использованием устройств linux md и 3 дисков SATA емкостью 1 ТБ
• 2 карты Ethernet, подключенные к двум разным сетям в нашем офисе (проводная и беспроводная сеть)

Я подозревал, что, возможно, RAID-массив был поврежден / неисправен, поэтому я запустил mdadm --detail и он сообщил, что состояние было clean и все диски были в active sync . Для дальнейшего тестирования я скопировал файл 1 ГБ с SD-карты в массив RAID, и сумма md5 этого файла была проверена.

Что может происходить?

РЕДАКТИРОВАТЬ: Вывод cmp -l в соответствии с запросом:

324268145 115 105
324268657 274 264
324269297 332 322
324270577 345 344
324270833 155 154

РЕДАКТИРОВАТЬ 2: Я только что понял, что одна из моих копий действительно имеет правильную контрольную сумму MD5, поэтому я скопировал файл с моего локального компьютера еще два раза, и оба раза контрольная сумма была правильной! Итак, еще несколько тестов в порядке здесь ...

EDIT3: теперь я не могу воспроизвести эту проблему. Что звучит как плохая память для меня. Сегодня вечером будет проведен мемтест, приветствуются любые другие идеи!

EDIT4: хорошо. Теперь это странно. Проблема воспроизводится на 100% при копировании файла на конкретную виртуальную машину VMWare, запущенную на сервере. Если я копирую файл на эту виртуальную машину, иногда, если я немедленно копирую файл на хост, проблема воспроизводима. scp также иногда говорит это при копировании на виртуальную машину:

Received disconnect from 10.1.0.73: 2: Packet corrupt

Все это кажется мне ключом к плохой оперативной памяти. Все согласны? Любые другие возможные объяснения?

РЕДАКТИРОВАТЬ5: Решено. Ну и дела, что могло вызвать эту проблему? Я просто не понимаю .... :-)

(Я протестировал RAM на этой системе сразу после того, как купил ее, что было два-три месяца назад ... да ладно. Похоже, пришло время звонить в Dell ...)

Answer 1

Два файла имели одинаковый размер? Если нет, то один из файлов, вероятно, был усечен.

Если вы использовали FTP для передачи файлов, некоторые клиенты по умолчанию принимают текстовые файлы, и им нужно сказать, чтобы они перешли в двоичный режим, иначе они будут искажать ^M и ^J Когда-то это был основной источник поврежденных файлов, но в настоящее время это редкость.

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

Однако ни одна из вышеперечисленных возможностей не может удовлетворительно объяснить третье значение md5sum.

Попробуйте сравнить файлы (например, с помощью cmp -l) и посмотрите, есть ли закономерность в различиях. Если вы видите, что различия всегда кажутся в определенных битовых позициях (что-то вроде всегда в самом старшем бите позиции байта в форме 8 * n+3), это, как правило, признак того, что ваша RAM неисправна. Как правило, в случае повреждения данных, которое не может быть объяснено программным обеспечением или передачей по сети, ОЗУ стоит первым.

Answer 2

Если вы осуществляете передачу по FTP, используйте передачу в двоичном режиме. В противном случае любые окончания строки в файле будут искажены. Windows не нужно манипулировать ограничителями строки в текстовом режиме.

Answer 3

В качестве быстрой проверки, если вы передаете файл с помощью sneakernet (то есть, поместите его на флэш-накопитель и просмотрите его), он работает нормально?