Чому rsync не використовує дельта-передачу для локальних файлів?


25

У мене є велике ізо-зображення, яке зараз завантажується торент-клієнтом із увімкненою резервацією простору: це означає, що розмір файлу не змінюється, а деякі фрагменти в (4 Міб) постійно змінюються через завантаження.

При завантаженні на 90% я роблю початковий rsync, щоб згодом заощадити час:

$ rsync -Ph DVD.iso / media / Another-hdd /
надсилання додаткового списку файлів

DVD.iso
       2.60G 100% 40.23MB / s 0:01:01 (xfer №1, для перевірки = 0/1)

надіслано 2,60 байтів, отримано 73 байти 34,59 М байт / сек
загальний розмір - 2,60 прискорення - 1,00

Потім, коли файл повністю завантажений, я знову rsync:

total size is 2.60G   speedup is 1.00

Speedup = 1 говорить, що передача дельти не використовувалася, хоча 90% файлу не змінилося, цільовий dir знаходиться на іншому FS, а копіювання займає кілька хвилин. Чому не намагаються прискорити передачу ?! Як змусити rsyncвикористовувати дельта-передачу?


6
Те, що ви робите, не має жодного сенсу. Мета rsync - прискорити передачу файлів по мережі, а не локально. Щоб знайти відмінності, він повинен прочитати і джерело, і місце призначення. У той час, коли потрібно прочитати місце призначення, щоб знайти відмінності, ви можете просто зробити звичайну копію. Просто завантажте файл до місця призначення, а не копіюйте його.
psusi

1
Так що він просто не використовує delta-xfer, оскільки, працюючи локально, швидше скопіювати, ніж обчислити хеші? Якщо так - опублікуйте відповідь plz :)
kolypto

9
Читання може бути швидшим, ніж запис на локальний диск за певних обставин. Це також може зменшити знос SSD. Це, безумовно, справедливе питання, і відповідь для мене досить цінна.
HRJ

2
@psusi, окрім коментаря HRJ вище, також враховує випадок, коли цільовий файл був перейменований (наприклад, на btrfs або ocfs2). Мінімізація записів під час синхронізації може внести величезні зміни до загального використання простору.

Відповіді:


20

Згідно сторінці керівництва , psusi прав:

-W, --whole-file : Передача може бути швидшою, якщо цей параметр використовується, коли пропускна здатність між джерелом і машинами призначення перевищує пропускну здатність до диска (особливо, коли "диск" насправді є мережевою файловою системою). Це за замовчуванням, коли і джерело, і пункт призначення вказані як локальні шляхи, але тільки якщо не існує жодної опції пакетного запису.


10
О, дякую! Я змінив цю лінію :) Щоб увімкнути дельта-трансфер, використовуйте-no-W
kolypto

1
У моїй системі -no-Wне працює лише довгий варіант -no-whole-file. Моя причина необхідності цього перемикача полягає в тому, що я встановлюю резервну копію та маю великі файли (наприклад, зображення), які не мають однакового часу на модифікацію. Набагато швидше, швидкість 163,26, щоб синхронізувати ці файли за допомогою передачі дельта в моїй локальній файловій системі.
Джессі Вітер Мандрівник

6
@JessetheWindWanderer, довгий варіант - це --no-whole-file(будь-ласка, зверніть увагу на подвійний --на початку).
Едді К.

Дякую Едді К. Я б відредагував свій коментар, якби я міг зрозуміти, як :-(
Джессі

17

Пряма відповідь на це питання:

Використовуйте --no-Wпрапор, щоб примусити дельта стиснення, незалежно від локального чи віддаленого.

Оновлення: Схоже, до історії є більше. delta compression, Здається, включається тільки між отримувати і обробляти передачі в Rsync. При виведенні файлу у файлову систему, rsyncможливо, все-таки виписується весь файл (и), навіть із увімкненою дельтою стиснення.

Дивіться розслідування "Вакан Танки" тут .


2
--no-Wзавжди передайте весь файл у моєму випадку. Перевірте unix.stackexchange.com/questions/291156/…
Tanka

@WakanTanka Це цікаво! Я оновив свою відповідь.
HRJ

3

За замовчуванням rsync спочатку створює нову копію цільового файлу, а потім замінює його з різних причин безпеки. Ви можете змінити це, вказавши --inplaceпоряд із --no-whole-file. Це спонукає rsync здійснити внутрішнє редагування цільового файлу, приймаючи різні ризики (як правило, незначні для цієї ситуації), як це зафіксовано на сторінці "man".


0

За замовчуванням rsyncстворює копію файлу в пункті призначення, а потім атомарно замінює оригінал новою копією. Це робиться з міркувань безпеки. Те, що ви шукаєте, - це --inplaceваріант, який призведе rsyncдо зміни лише частин файлу призначення, які змінилися відносно джерела.

У випадку використання ОП я також рекомендую вимкнути попереднє розподілення, щоб синхронізувати копію, що буде набагато швидше. Для завантаження не хвилюйтесь про фрагментацію, якщо ви не використовуєте дуже давню файлову систему, наприклад VFAT. Зокрема, медіафайли не читаються при максимальній продуктивності носія інформації, тому дефрагментація їх є марним зусиллям.

Щоб копіювати каталог завантажень в рідкий об'єм, я рекомендую ці прапорці та операції в такому порядку:

rsync --ignore-existing -vxaHAXS /source /destination
rsync --inplace -vxaHAX /source /destination

Перший пропуск буде копіювати нові файли рідко до місця призначення. Другий пропуск оновить наявні файли на місці, копіюючи лише зміни

Оскільки він робить рідкісні та встановлені на дельті копії, ви можете запускати це неодноразово, не створюючи багато зайвого вводу-виводу. Навіть якщо у вас одночасно працює 20 торрентів, це не посилить запис у пункті призначення, ані обміняння томів / джерел.


Що ти маєш на увазі під "рідко" тут, Віл? Наскільки я можу сказати, це насправді не відображає фактичного значення цього слова.
Юлій

@Julius: це означає саме те, що має на увазі - скопіюйте файли з повною підтримкою розрідженого розподілу, так що, наприклад, ваші фільми з форматом HDR 40 Гб не займуть більше місця в місці призначення, ніж у джерелі. Те саме із зображеннями дисків VirtualBox. Як зазначалося, ОП потрібно було б відключити попередній розподіл, щоб це працювало.
Віл
Використовуючи наш веб-сайт, ви визнаєте, що прочитали та зрозуміли наші Політику щодо файлів cookie та Політику конфіденційності.
Licensed under cc by-sa 3.0 with attribution required.