Как раз контрольная сумма для всего файла rsync'ом не считается, а он делится на участки (65536 участков максимум, если не ошибаюсь). А вот почему нет параллельного просчёта - непонятно. Сервера обычно ставят на рейд, например raid10 - там скорость доступа может сильно не проседать. Или сейчас вообще на SSD модно.
У виртуалок на базе образа диска (KVM, VMWare) есть несколько больших файлов. С OpenVZ ситуация другая.
Parallel Rsync в основном нужен когда несколько миллионов файлов синхронизируется. Для одного он неприменим.
Мне нужно как раз образы виртуалок.
Я посмотрел статистику по дисковым и сетевым операциям - rsync показыает в --progress какую-то непонятную цифру, не сильно связанную с реальностью. Во всяком случае это точно не скорость передачи по сети и не скорость чтения с диска. Возможно, на гигабитных каналах ему надо какие-то параметры выставлять специфические. Интернет ответа не дал. Но процессор всё равно используется один и на 100%, так что думаю что проблема именно в нём.
Судя по всему проблема в подсчёте контрольных сумм - процессора не хватает, на обеих сторонах 100%.
--block-size в новых версиях rsync должен выбираться автоматически исходя из размера файла, и менять его нет смысла.
Узнаёте какая у Вас ОС, гуглите или спрашивайте конкретно. Зачем телепатию призывать?---------- Добавлено 09.12.2015 в 15:46 ----------
https://www.google.ru/search?q=ext2+undelete - пример для ext2. Делаете образ виртуалки, запускаете, экспериментируете. Вы же её остановили, и у ВАс не OpenVZ ?
bittorentsync это ад для серьёзного использования. Он полностью непредсказуем.
Я думал так сделать, но цифры такие: скорость чтения/записи с диска 600Мб/сек, скорость rsync - 100Мб/сек. Тест:
split -b 1G vm-disk-2.vmdk
cat x* >vm-disk-2.vmdk-copy
rm x*
split -b 1G vm-disk-1.vmdk
cat x* >vm-disk-1.vmdk-copy
real 16m26.977s
user 0m0.796s
sys 3m0.672s
rsync на тех же файлах выдаёт
real 17m49.501s
user 12m41.816s
sys 1m4.081s
то есть с разбиением получается ещё хуже.---------- Добавлено 09.12.2015 в 13:23 ----------
Первое - это мечта всех виртуальщиков. Второе - упрётся в процессор и диск, см. Пример выше.
изменяющихся данных 100 мегабайт. 100 гигабайт будет качаться сутки.
Если речь идёт о физическом сервере, то я бы использовал какую-нибудь виртуализацию. LXC например. Заодно бонусы получились бы.
... а там тоже стоит "Самая надежная защита от спама". С каптчей, конечно. ---------- Добавлено 02.12.2015 в 16:53 ---------- Свежая альтернатива - это постфикс + грейлистинг. Вы как минимум знаете что у вас происходит в системе и как это быстро прекратить. Остальные варианты будут присылать Вашим корреспондентам всякие оскорбительные подозрения в спамерстве.
И не надо бояться нескольких писем со спамом в день. Очень неприятно бывает найти в спам-папке письмо, попавшее туда по ошибке.
А разве ceph может обеспечить бэкапы консистентней чем lvm2 какой-нибудь, который всё равно их не обеспечивает? Мне казалось, Что ceph нужен для надёжности и живой миграции.
