Разное значение хэша большого rsync-файла на centos и ubuntu?

Разное значение хэша большого rsync-файла на centos и ubuntu?

Я синхронизировал большой файл с удаленного CentOS на локальный Ubuntu с помощью

rsync -avzP user@<remote-ip>:/path/to/file .

Сообщается, что перевод прошел успешно:

sent 30 bytes  received 257,293,476 bytes  1,296,188.95 bytes/sec
total size is 8,217,194,015  speedup is 31.94

Насколько мне известно, rsync автоматически проверяет успешность передачи с помощью хэш-проверок после завершения передачи.

Из любопытства я вычислил хэши md5 на centos и ubuntu, и они различаются:

centos: 0faa300b7b0b81bfe65199da932eb6e2
ubuntu: f3a0fcc59516d4e68fd207bdbb1fc169

Оба хеша вычисляются с помощью md5sum:

centos> md5sum --version
md5sum (GNU coreutils) 8.22

ubuntu> md5sum --version
md5sum (GNU coreutils) 8.25

Итак, версии немного отличаются, но может ли это привести к разным значениям хэшей?

Редактировать:

Вот ls -lрезультаты:

centos: -rw-rw-r--.  1 username username 8217194015
ubuntu: -rw-rw-r--   1 username username 8217194015

В выводе Centos есть загадочная точка, о которой я никогда не слышал. (может ли это быть связано с lvm? lvm используется на этом centos)

Редактировать 2:

Проверка md5sum -bтакже приводит к разным результатам:

centos: 0faa300b7b0b81bfe65199da932eb6e2
ubuntu: 6d799f6981066d82c7f861576b4980e1

Какой алгоритм хеширования использует rsync?Согласно Википедииrsync использует md5 для проверки идентичности фрагмента:

Получатель разбивает свою копию файла на части и вычисляет две контрольные суммы для каждой части: хэш MD5 и более слабую, но более простую для вычисления «скользящую контрольную сумму». Он отправляет эти контрольные суммы отправителю. Отправитель быстро вычисляет скользящую контрольную сумму для каждой части в своей версии файла; если они отличаются, ее необходимо отправить. Если они одинаковы, отправитель использует более затратный в вычислительном отношении хэш MD5 для проверки того, что части одинаковы.

решение1

Здесь есть неверное предположение:

Насколько мне известно, rsync автоматически проверяет успешность передачи с помощью хэш-проверок после завершения передачи.

Rsync использует контрольные суммы для определения необходимости синхронизации. Но Rsync не перечитывает созданную копию, доверяя ядру сообщать об ошибках. Итак, вывод прост: файлы не идентичны. Может быть, всего один бит, может быть больше. Насколько велико несоответствие, контрольная сумма вам не скажет.

решение2

Точка .означает, что файл имеет контекст SELinux, как и любой файл в CentOS (и ни один файл в Ubuntu), что может сбивать md5sumс толку. Вы пробовали запустить md5sumс bswitch, чтобы убедиться, что он не будет испорчен преобразованиями "в текст"?

Связанный контент