Выполняет ли rsync контроль над любой контрольной суммой?

Мне нужно перенести файлы с нескольких серверов на один удаленный хост, используя Rsync через SSH. Тем не менее, я должен быть уверен, что до того, как файл будет удален из источника, используя аргумент -remove-from-source, фактически переданный файл.

Из того, что я читал, нет контрольных сумм передачи сообщений, а rsync доверяет ответ ядра, но эти статьи были датированы с 2005-2009 годов. Мне было интересно, изменилось ли это в последних обновлениях на rsync? Если нет, то какой метод (ы) должен проверить это, а затем удалить исходный файл после проверки?

Изменить: я не понимаю, как это дубликат. Мой вопрос не относится к локальным дискам в одной системе …

  • Chroot пошел не так, не может ssh с пользователем
  • Как изменить заголовок активного терминала после SSH
  • Используйте настольные динамики через SSH с ноутбука
  • Изменен SSH-порт, не разрешив его через брандмауэр, заблокированный сейчас - что делать?
  • Вызов сценария Bash ожидает сценария с основным SSH-соединением
  • rsync через SSH иногда очень медленно - в других случаях максимальная пропускная способность
  • Конфигурация ssh от Ubuntu 12.04 не работает 14.04.4
  • Поиск и управление файлами на внешнем жестком диске через FileZilla через SSH
  • One Solution collect form web for “Выполняет ли rsync контроль над любой контрольной суммой?”

    Резюме : Если rsync получает данные на диск, он будет делать это без потерь. Однако, чтобы быть абсолютно уверенным, что на самом деле были данные на диск , вам нужно будет применить патч fsync.diff или впоследствии вызвать sync <files> .


    SSH обеспечивает целостность данных – вы получаете те же данные, что и вы отправляете. Это объясняет сеть.

    Затем rsync использует системный вызов записи, запрашивая ядро ​​для записи данных на диск. Если ваш жесткий диск не работает (другой вопрос), это также сохраняет целостность данных.

    Однако, гарантируя, что данные на самом деле находятся на диске, теперь досадно не так просто. На странице руководства по write делается следующее замечание:

    Успешный возврат из write () не гарантирует, что данные были записаны на диск. Фактически, при некоторых ошибках реализации он даже не гарантирует, что пространство было зарезервировано для данных. Единственный способ убедиться в том, что вы вызовете fsync (2) после того, как вы закончите запись всех ваших данных.

    Я загрузил последний (3.1.2pre1) rsync исходный код, grepped для fsync и ничего не получил. По умолчанию rsync не вызывает fsync (я также сделал grepped для версии без метаданных fdatasync : тоже ничего). Это означает, что эти write ничего не сделали, но зависят от файловой системы.

    В качестве решения вы можете:

    • Запустите sync <files> , который вызывает fsync для данных файлов. Когда это вернется, они определенно находятся на диске.

    • Загрузите директорию исходных исправлений rsync (предоставляется в виде отдельной загрузки). Примените патч fsync.diff Сами Фарин. Он «позволяет указать –fsync, если вы хотите, чтобы fsync () вызывался в каждом файле, который мы пишем». (Это, надеюсь, станет дефолтом в будущем.)

    Обычно , современные файловые системы делают ваши записи Pretty Soon ™, лишь кратко воспользовавшись их свободой кэширования при высокой загрузке ввода-вывода. Если вы знаете свою систему, возможно, вы справитесь с этим шагом. Но имейте в виду, когда вы пишете код для более широкого использования, результаты могут отличаться в зависимости от вашей файловой системы, от того, как она настроена, и является ли божество прошивки на ходу доброжелательным.

    Linux и Unix - лучшая ОС в мире.