Война с rsync
Отцы,
алчу совета мужей, искушенных в работе такой штуки, как rsync.
В чем суть проблемы: стоит у меня дома NAS, с которым почти все мои компы связаны по протоколу NFS. Периодически я бэкаплю свои виртуальные машины на этот самый NAS. На NAS'е стоят обьединенные в райд два 12 Тб диска, работают безупречно. Так вот:
Если просто скопировать вот так:
cp -r /../..../VMs /mountpoint/backup
то все работает хорошо. Никаких проблем и подлян.
но если сделать вот так:
rsync -rzp --no-links --timeout=600 --block-size=131072 --temp-dir=$TMP_DIR --omit-dir-times --progress $VM_DIR $VM_BACKUP_PATH
То при копировании очередного файла в ...цать гигов размером выскакивает ошибка I/O error code 5. Разумеется, бэкап-копия неработоспособна.
Я пробовал самые разные наборы ключей rsync, перелопатил гугл вдоль, поперек и наискосок, но как-то сильно легче не стало: эта ошибка лезет стабильно и регулярно. Дисковая система на машине-источнике и на NAS в полном порядке, это проверено. Пороговое значение размера файла, при котором возникает вот такое, где-то около 15-20 Гб.
Вопрос: кто-нибудь с таким сталкивался? Поборол?
Спасибо заранее.
Update. Выглядит это вот так:
rsync: close failed on "/mnt/backup/vm/Home WinXP old/Snapshots/{8fae1264-907e-4b44-9469-b2dfe228ea7e}.vdi": Input/output error (5)
rsync: copy "/home/alex/TMP2/{8fae1264-907e-4b44-9469-b2dfe228ea7e}.vdi.71oevA" -> "Home WinXP old/Snapshots/{8fae1264-907e-4b44-9469-b2dfe228ea7e}.vdi": Input/output error (5)
rsync: close failed on "/mnt/backup/vm/Oleg/Oleg-disk1.vdi": Input/output error (5)
rsync: copy "/home/alex/TMP2/Oleg-disk1.vdi.ux7u0x" -> "Oleg/Oleg-disk1.vdi": Input/output error (5)
rsync: close failed on "/mnt/backup/vm/Windows-64/Windows-64.vdi": Input/output error (5)
rsync: copy "/home/alex/TMP2/Windows-64.vdi.e2suQA" -> "Windows-64/Windows-64.vdi": Input/output error (5)
total: matches=0 hash_hits=0 false_alarms=0 data=105305415757
sent 56,641,261,873 bytes received 2,238 bytes 12,672,841.28 bytes/sec
total size is 166,176,618,172 speedup is 2.93
rsync error: some files/attrs were not transferred (see previous errors) (code 23) at main.c(1207) [sender=3.1.3]
- cynic's blog
- Login to post comments
Я сварщик не
Я сварщик не настоящий и лично с этой хренью дела не имел, но на моей памяти два джедая трахались с этой штукой "по настоящему". Из того, что я запомнил оно вроде как совсем не может большие файлы обрабатывать в силу кривой архитектуры - оно пытается каждый файл целиком в память засосать, соответственно, если размер свопа меньше, то привет-приехали, особенно на не-х86 системах.
Я
Я принципиально в это не уперся, в конце концов можно именно виртуальные машины копировать просто cp, но всегда есть шанс, что ты накосячил и проблема кем-то и как-то на самом деле уже давно решена. Да и потом штука вроде серьезная, не вчера придуманная.
Именно что, не
Именно что, не то что "не вчера", а позавчера. А позавчера файлов размером в несколько десятков гигов в природе не существовало.
1. $TMP_DIR куда
1. $TMP_DIR куда примонтировано? Там хватает места?
2. Это 100% воспроизводимо? Если копировать один и тот же большой файл несколько раз подряд?
Еще посмотреть бы как оно падает с --debug и --msgs2stderr.
1. Там с местом
1. Там с местом все хорошо.
2. Я попробую с этими ключами запустить.
dmesg | tail nfsstat
dmesg | tail
nfsstat -rc
ethtool -S ethX
rsync -vv ?
ala
rsync -vvrzp --no-links --timeout=600 --block-size=131072 --temp-dir=$TMP_DIR --omit-dir-times --progress $VM_DIR $VM_BACKUP_PATH
обычная
обычная команда copy работает на ура, с сетью тоже все хорошо. Не пропадает соединение с сервером.
Раз все
Раз все работает попробуйте delayed ack посмотреть на клиенте с которого шара монтируется
slow start SetNoDelayedAck
более глобально разбор тут https://www.vmware.com/content/dam/digitalmarketing/vmware/en/pdf/techpa...
ну и strace/ptrace
если оно падает
Оно не падает,
Оно не падает, оно заканчивает работу вот с такой диагностикой, которую я привел в конце оригинального сообщения.
Вопрос: почему вы считаете, что настройки TCP/IP будут играть какую-то роль? классическая команда cp работает с имеющимися настройками и все проходит хорошо. Почему надо менять настройки протокола специально под rsync?
возьмусь
возьмусь предположить что нас либо железный, либо софт стоит на нем давно и долго.
отсюда переходим к клиенту, на клиенте могли обновить либы, сещуритипачес, ядро
смотреть версию ядра, клиентов, на то что обновляли в последнее время и ченджлоги
я бы натравил strace/prace на процесс, записал дамп что бы понять почему падает