Rsync через ssh каждый раз копирует все файлы

Это пропорционально и не зависит от объема памяти. Код находится в mm/vmscan.c. После проверки некоторых патологических состояний, таких как полное отсутствие пространства подкачки (, только файлы -резервных страниц будут сканироваться как кандидаты на вытеснение из памяти ), так как память почти закончилась (файл -резервная и анонимная память будут сканироваться одинаково ), или кеш страниц стал очень большим и заполнен неактивными страницами (будут сканироваться только файлы -резервные страницы ), мы нажимаем это:

/*
 * With swappiness at 100, anonymous and file have the same priority.
 * This scanning priority is essentially the inverse of IO cost.
 */
anon_prio = swappiness;
file_prio = 200 - anon_prio;

Эти приоритеты корректируются в зависимости от успехов сканера памяти в недавнем освобождении памяти каждого типа. Затем память каждого типа сканируется пропорционально, и страницы, которые не использовались в последнее время, будут вытеснены.

В итоге все зависит от рабочей нагрузки. Значение подкачки сообщает системе, какой приоритет следует присвоить попыткам выгрузки анонимной памяти, но шаблоны доступа к памяти будут определять, что на самом деле произойдет.

1
16.11.2019, 04:41
1 ответ

Из вашего вывода:

<f..t...... BTEVC/Untitled41.mov

Нижний регистр tуказывает, что rsync (пытается )установить время в пункте назначения, чтобы оно соответствовало источнику. Все остальное после fпусто, указывая на то, что они соответствуют (, поэтому вам не нужно смотреть на разрешения пользователя, являющиеся причиной ).

Возможно, вы захотите изучить время до и после пробежки, чтобы увидеть, чем они отличаются.

Предложения:

  • Попробуйте --inplace. Посмотрим, изменится ли что-нибудь
  • Скопируйте один файл (, чтобы результат был меньше ), а затем увеличьте детализацию. С помощью -vvvвы можете попытаться установить время передачи аналогично :

    .
    [...]
    recv mapped dest.file of size 598
    got file_sum
    set modtime of.dest.file.5s3OoJ to (1573876681) Fri Nov 15 19:58:01 2019
    renaming.dest.file.5s3OoJ to dest.file
    [...]
    

Посмотрите, не сообщается ли что-нибудь странное вокруг этой точки (и совпадает ли фактическая отметка времени после этого)

$ stat dest.file
  File: dest.file
  Size: 598             Blocks: 1          IO Block: 65536  regular file
Device: 8788005h/142114821d     Inode: 19140298416802240  Links: 1
Access: (0755/-rwxr-xr-x)  Uid: (197609/ compusr)   Gid: (197121/    None)
Access: 2019-11-15 20:26:49.597544100 -0800
Modify: 2019-11-15 19:58:01.309978600 -0800
Change: 2019-11-15 20:26:49.598968100 -0800
 Birth: 2019-11-15 20:26:49.594376800 -0800
1
27.01.2020, 23:40

Теги

Похожие вопросы