Неправильный md5sums на загруженных файлах
У меня есть LTS Ubuntu 10.04.1 сервер Linux, который испытывает некоторые странные проблемы... Я просто попытался загрузить 440 МБ tgz заархивируйте по 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 CPU
- ПОРШЕНЬ НА 8 ГБ
- Программное обеспечение массив RAID5 с помощью Linux md устройства и 3 диска SATA на 1 ТБ
- 2 платы Ethernet, подключенные к двум различным сетям в нашем офисе (проводное и беспроводная сеть)
Я подозревал, возможно, что RAID-массив ухудшался/неправильно функционировался, таким образом, я работал mdadm --detail и это сообщило, что состояние было clean и все диски были в active sync. Для дальнейшего тестирования я скопировал файл на 1 ГБ от SD-карты до RAID-массива и md5sum того проверенного файла.
Что могло продолжаться?
Править: Вывод cmp -l согласно просьбе:
324268145 115 105
324268657 274 264
324269297 332 322
324270577 345 344
324270833 155 154
EDIT2: Я просто понял одну из копий, которые я имею, на самом деле имеет корректную контрольную сумму MD5, таким образом, я скопировал файл со своей локальной машины еще два раза, и оба раза контрольная сумма была корректна! Таким образом, еще несколько тестов в порядке здесь...
EDIT3: Я теперь не могу воспроизвести эту проблему. Который походит на плохую RAM мне. Выполнит memtest сегодня вечером, любые другие одобренные идеи!
EDIT4: хорошо. Теперь это странно. Проблема на 100% восстанавливаема, когда копирование файла к определенной виртуальной машине VMware работает на сервере. Если я копирую файл в ту виртуальную машину, иногда если я сразу копирую файл в хост, проблема восстанавливаема. scp также иногда говорит это при копировании в виртуальную машину:
Received disconnect from 10.1.0.73: 2: Packet corrupt
Они все, кажется, мне подсказки плохой RAM. Все соглашаются? Какие-либо другие возможные объяснения?
EDIT5: Решенный. Ну и дела, что же, спрашивается, возможно, вызывало эту проблему? Я просто не понимаю.... :-)
(Я действительно тестировал RAM в этой системе прямо после того, как я купил ее, который равнялся двум три месяца назад..., о, хорошо. Похож пора назвать Dell...),
3 ответа
Эти два файла имели тот же размер? В противном случае один из файлов был, вероятно, усеченным.
Если Вы использовали FTP для передачи файлов, некоторые клиенты принимают текстовые файлы по умолчанию и должны быть сказаны войти в режим двоичного счета, или они исказят ^M и ^J. Это было однажды основной источник поврежденных файлов, но является редкостью в наше время.
Пакеты TCP имеют 16-разрядную контрольную сумму. Это означает, что приблизительно одна ошибка в 65 536 пойдет необнаруженная, таким образом, ошибка передачи будет в пределах возможного.
Ни одна из возможностей выше удовлетворительно не объясняет третье значение md5sum, все же.
Попытайтесь сравнить файлы (например, с cmp -l) и посмотрите, существует ли шаблон к различиям. Если Вы видите, что различия всегда, кажется, в определенных позициях двоичного разряда (что-то как всегда на уровне наиболее значимого бита положения байта формы 8*n+3), это обычно - знак, что Ваша RAM является дефектной. Обычно в случае повреждения данных, не объяснимого программным обеспечением или сетевой передачей, RAM является первым местом для взгляда.