Мы запускаем скрипт резервного копирования, который сначала копирует файл в место назначения, а затем запускает tarего.
DIR2BCK='/foo/bar' TMPDIR=$(mktemp -d) rsync -a $ $/ > /dev/null 2>&1 tar czf /tmp/foo.backup.tar $
После выполнения этой последней команды иногда отображается следующее предупреждение:
/tmp/tmp.blqspkA136: файл изменился, когда мы его читали
Мы копируем место назначения во временный каталог точно, чтобы избежать изменений файла во время сжатия. Это поведение также воспроизводимо при использовании cpкоманды вместо rsync. Всю свою жизнь я думал, что эти команды были синхронными, но это предупреждение, кажется, показывает обратное.
Если я поставлю sleepкоманду между rsync/ cpи tarстроками, предупреждение не появится, но я считаю это не совсем чистым решением.
Некоторые факты:
Я попытался добавление syncкоманды между rsyncи tarкомандами с тем же результатом.
По предложению @jcbermu я также попытался изменить скрипт так, чтобы две строки:
rsync -a $ $/ > /dev/null 2>&1 & wait
Я запускаю скрипт несколько раз, и некоторые из них демонстрируют одинаковое поведение, утверждая, что файл изменился при копировании.
Используемая файловая система - EXT4 как для, так $и для $.
$находится на удаленной файловой системе, на самом деле это точка монтирования samba удаленной машины. $находится на локальной файловой системе. Однако переход $на локальную файловую систему не имеет значения.
Все файловые системы основаны на аппаратном RAID-5.
Эти команды на самом деле синхронны? Если нет, есть ли способ сделать их так, или альтернативная команда?
Да, эти команды выполняются при выходе. Вы не цитируете имена файлов / каталогов. Пожалуйста, исправьте это как можно скорее.
Daniel B 7 лет назад
0
@DanielB Моя ошибка. Хотя логика та же самая, это не настоящий код. Настоящий включает в себя цитаты.
nKn 7 лет назад
0
Что ж, возможно, в * реальном * коде есть небольшая ошибка. Или приведенного выше кода на самом деле достаточно, чтобы воспроизвести проблему?
Daniel B 7 лет назад
0
Да, этого должно быть достаточно, так как пути правильные. Основная проблема заключается в том, что когда запускается tar, `rsync` /` cp`, похоже, еще не закончил копирование, и отображается предупреждение. Я предполагал, что эти команды синхронны, поэтому я удивлен.
nKn 7 лет назад
0
Не предполагай, попробуй. В противном случае квалифицированный ответ не может быть предоставлен. // `sync` здесь не помогает. Вы не получаете доступ к необработанным данным на устройствах. // Пожалуйста, также предоставьте информацию о том, на каких файловых системах находятся `$ TMPDIR` и` $ DIR2BCK`.
Daniel B 7 лет назад
0
Находятся ли и $ TMPDIR, и $ DIR2BCK в одной файловой системе? или это отдельные диски или разделы? Используете ли вы обычные жесткие диски / SSD или какой-то другой RAID?
arielnmz 7 лет назад
0
@arielnmz они находятся в отдельных файловых системах, `$ ` на самом деле является общим ресурсом samba на другом компьютере, но это также происходит, когда оба находятся в одной файловой системе. Все файловые системы на RAID5.
nKn 7 лет назад
0
2 ответа на вопрос
0
jcbermu
Одним из решений является переписать его как:
rsync -a $ $/ > /dev/null 2>&1 ; tar czf foo.backup.tar $
Итак, tarне начнется до rsyncконца.
Другое решение - отправить cp/ rsyncв фоновый режим и подождать, пока он не закончится командой wait.
Например:
rsync -a $ $/ > /dev/null 2>&1 & wait tar czf foo.backup.tar $
Последний &в rsyncстроке отправляет выполнение в фоновый режим (он становится дочерним элементом текущего сеанса), а затем waitвынуждает этот сеанс оболочки ждать, пока все дочерние элементы не закончили, чтобы продолжить.
Проблема с первым подходом заключается в том, что он эквивалентен тому, который я использую. Разделение двух команд на две строки - это то же самое, что и одна строка с разделителем `;`. Никто из них не должен запускать строку `tar` до тех пор, пока команды` rsync` / `cp` не завершатся, если они синхронны, но в этом случае этого не происходит. Я попробую второй подход и вернусь.
nKn 7 лет назад
1
К сожалению, предложенное вами изменение показало то же поведение в некоторых циклах, я отредактировал свой вопрос, добавив этот тест.
nKn 7 лет назад
0
0
TOOGAM
Я поместил команду сна между строками rsync / cp и tar, предупреждение не появляется, но я считаю, что это не совсем чистое решение.
Хорошо для вас или иметь стандарты. Что произойдет, если вместо сна вы используете:
синхронизация sudo; эхо 3 | sudo tee / proc / sys / vm / drop_caches
Считаете ли вы это хорошим решением?
Примечание: похоже, что Ubuntu использует / proc / sys / vm / drop_caches и не подходит для всех Unix-систем (хотя, может быть, для всех Linux). Я упоминаю об этом после прочтенияhttps://ubuntuforums.org/showthread.php?t=589975 и, после прочтения первоначального отчета, ставящего под сомнение безопасность этого, прочитайте больше постов на форуме, подтверждающих его безопасность.
Я забыл упомянуть в своем вопросе, но уже попробовал команду `sync`, но безуспешно. Я попробовал как локальную файловую систему, так и удаленную как описание копии, но происходит то же самое. `Drop_caches` не подходит для нас, так как мы используем много разных ОС (CentOS, Ubuntu, Debian ...).
nKn 7 лет назад
0