Я полагаю, что Вы используете зеркало, которое это (выход) из синхронизации.
p11-kit
, vim-runtime
пакеты были обновлены 01.04.2012 и 10.04.2012 соответственно. Пакет Nvidia был обновлен сегодня (2012-04-11), таким образом, все, что необходимо сделать, является ожиданием некоторое время.
Довольно интересно, что у Вас есть a linux
версия пакета 3.3, хотя и a gvim
пакет с 10.04.2012. Вы изменяли репозитории (отключенный testing
) или зеркала в последнее время? Вы могли бы хотеть использовать mirrorlist или mirrorlist updater для нахождения актуального зеркала около Вас. Это, скорее всего, также восстановило бы Ваш extra
файл дб.
Я думаю, что эти различия довольно хорошо устанавливаются между cp
и rsync
. См. эту статью как ссылку, названную: взгляд rsync производительность.
The four commands tested were:
rsync $SRC $DEST
echo $SRC | cpio -p $DEST
cp $SRC $DEST
cat $SRC > $DEST/$SRC
The results for rsync, cpio, cp, and cat were:
user sys elapsed hog MiB/s test
5.24 77.92 101.86 81% 100.53 cpio
0.85 53.77 101.12 54% 101.27 cp
1.73 59.47 100.84 60% 101.55 cat
139.69 93.50 280.40 83% 36.52 rsync
Я использую rsync
ежедневно. Существуют вещи, которые можно сделать для улучшения ситуации.
Например, можно попытаться использовать -W
переключатель:
-W, --whole-file copy files whole (w/o delta-xfer algorithm)
Также я предложил бы удостовериться, что Вы имеете 3.x версии rsync
. Были значимые улучшения, когда мы переместились до более новых версий.
Способ заставить rsync иметь то же представление в качестве CP состоит в том, чтобы записать его "CP".
Разница между двумя командами является значительной даже при том, что результирующий эффект может быть тем же. В частности, rsync делает набор чтения, чтобы видеть, должны ли некоторый файл или часть файла быть скопированы.
Есть ли некоторая причина, что Вы хотите использовать rsync? Поскольку CP копирует "вслепую", Вы будете видеть более высокую необработанную производительность. Если для ряда условий инициирования механизм "передачи дельты" rsync будет использоваться, то Вы будете видеть отбрасывание скоростей передачи и использование ЦП для повышения в значительной степени таким образом, Вы сообщаете.
rsync
не читает конечный файл при копировании, если Вы явно не включаете эту контрпродуктивную операцию с --whole-file
. В этой ситуации это точно так же, как очень медленное cp
.
– roaima
07.03.2018, 19:22
Для этого варианта использования rsync
является излишне сложной машиной. Если у вас все в порядке с синхронизацией, основанной на сравнении времени изменения файлов и размеров файлов, то только метаданные файловой системы должны собираться на обоих концах, сравниваться, а измененные (или новые )файлы должны быть скопированы с помощью (локальная команда )cp
.
Вас может заинтересовать этот небольшой и простой синхронизатор, который делает это:Fitus/Zaloha.sh
Используется следующим образом:
$ Zaloha.sh --sourceDir="test_source" --backupDir="test_backup"
Для максимальной скорости этапа анализавы можете пропустить генерацию сценариев восстановления :, используйте опцию --noRestore
. Кроме того, если у вас установлен быстрый mawk
, укажите опцию --mawk
, чтобы использовать его.
Zaloha.sh
собирает метаданные файловой системы с помощью команд find
. Один оставшийся вопрос касается производительности find
на вашем общем ресурсе NFS...