У утилиты синхронизации rsync есть такая опция --blocking-io
В мане написано:
--blocking-io
This tells rsync to use blocking IO when launching a remote shell transport. If -e or --rsh are not specified or are set to the default "rsh", this defaults to blocking IO, otherwise it defaults to non-blocking IO. You may find the --blocking-io option is needed for some remote shells that can't handle non-blocking IO. Ssh prefers blocking IO.

Вопрос: что означает фраза "This tells rsync to use blocking IO when launching a remote shell transport." ?
В момент синхронизации происходит блокировка на чтение/запись синхронизируемых файлов на удаленном хосте ? Да вроде нет: если на удаленном хосте файлы открыты на редактирование - все равно синхронизация происходит нормально.



p.s.
В свою очередь -e, --rsh - это вот что:
-e, --rsh=COMMAND
This option allows you to choose an alternative remote shell program to use for communication between the local and remote copies of rsync. By default, rsync will use rsh, but you may like to instead use ssh because of its high security.
You can also choose the remote shell program using the RSYNC_RSH environment variable.

Забыл добавить: это не праздный интерес.
Дело в том, что в определенные моменты rsync "валиться" с сообщением "error in rsync protocol data stream (code 12) at io.c(298)". Происходит это только на каталоге, который содержит файлы 200М и 300М. Все остальные участники синхронизации не содержат таких больших файлов и близко. Ошибка происходит предположительно в моменты, когда в эти файлы происходит запись.
Параметр --blocking-io убрал эту проблему, и файлы вроде продолжают нормально дописываться, но есть подозрение что данная опция rsync-а может заблокировать файлы как раз перед тем как их надо записывать.
Как я уже писал - на тестовых примерах все отрабатывает нормально, но запускать в промышленную эксплуатацию то, что вероятно может вызвать серьезный сбой системы - нельзя.