Чи rsync - замість запису на весь файл або просто на ті частини, які потрібно оновити? (для btrfs + резервного копіювання rsync)

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

Якщо ви пройдете rsync два локальних шляхи, він за замовчуванням використовує "--whole-файл", а не передачу дельти. Отже, ви шукаєте "--no-file-file". Ви також отримаєте дельта-передачу, якщо ви попросили "-c".

Ось як можна перевірити:

$ mkdir a b
$ dd if=/dev/zero of=a/1 bs=1k count=64
$ dd if=/dev/zero of=a/2 bs=1k count=64
$ dd if=/dev/zero of=a/3 bs=1k count=64
$ rsync -av a/ b/
sending incremental file list
./
1
2
3

sent 196831 bytes  received 72 bytes  393806.00 bytes/sec
total size is 196608  speedup is 1.00

Потім торкніться файла та повторно синхронізуйте

$ touch a/1
$ rsync -av --inplace a/ b/
sending incremental file list
1

sent 65662 bytes  received 31 bytes  131386.00 bytes/sec
total size is 196608  speedup is 2.99

Ви можете перевірити, що він повторно використовував inode з "ls -li", але помітите, що він надіслав цілих 64 К байт. Спробуйте ще раз з --no-file-file

$ touch a/1
$ rsync -av --inplace --no-whole-file a/ b/
sending incremental file list
1

sent 494 bytes  received 595 bytes  2178.00 bytes/sec
total size is 196608  speedup is 180.54

Тепер ви надіслали лише 494 байти. Ви можете використовувати strace для подальшої перевірки того, чи був записаний якийсь файл, але це показує, що принаймні використовується delta-transfer.

Зауважте (див. Коментарі), що для локальних файлових систем --whole-fileпередбачається (див. Головну сторінку для rsync). З іншого боку, по всій мережі --no-whole-fileпередбачається, тому --inplaceсама по собі буде вести себе як --inplace --no-whole-file.

Ось певна відповідь, я думаю, цитуючи правильну частину посібника:

   --inplace

          [...]

          This option is useful for transferring large files
          with  block-based  changes  or  appended data, and
          also on systems that are disk bound,  not  network
          bound.   It  can  also  help  keep a copy-on-write
                                               *************
          filesystem snapshot from diverging the entire con‐
          *******************
          tents of a file that only has minor changes.

--inplaceперезаписує лише регіони, які змінилися. Завжди використовуйте його під час запису до Btrfs.

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

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

На чоловіковій сторінці:

This  option  changes  how  rsync transfers a file when its data
needs to be updated: instead of the default method of creating a
new  copy  of  the file and moving it into place when it is com-
plete, rsync instead writes the updated  data  directly  to  the
destination file.

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

Теоретична робота про rsync на місці описана в цій роботі .

Довідка з паперу: Д. Раш та Р. Бернс. На місці Rsync: синхронізація файлів для мобільних та бездротових пристроїв. Щорічна технічна конференція USENIX, трек FREENIX, 91-100, USENIX, 2003.

За посиланням:

... Ми змінили існуючу реалізацію rsync для підтримки реконструкції на місці.

Анотація: [...] Ми змінили rsync, щоб вона працювала на обмежених простором пристроях. Файли на цільовому хості оновлюються в тому самому сховищі, яке займає поточна версія файлу. Пристрої з обмеженим простором не можуть використовувати традиційний rsync, оскільки для нього потрібна пам'ять або зберігання як для старої, так і для нової версії файла. Приклади включають синхронізацію файлів на стільникових телефонах та портативних ПК, які мають невелику пам’ять. Алгоритм rsync на місці кодує стиснене представлення файлу у графі, який потім топологічно сортується для досягнення властивості на місці. [...]

Таким чином, це, як видається, є технічними деталями того, що робить rsync - на місці. Відповідно до початку статті:

Ми змінили rsync, щоб вона виконувала завдання синхронізації файлів із реконструкцією на місці. [...] Замість використання тимчасового простору зміни цільового файлу відбуваються у просторі, який вже займає поточна версія. Цей інструмент можна використовувати для синхронізації пристроїв, де простір обмежений.

Як стає зрозуміло з відповіді @ dataless , це означає, що --inplaceвикористовується той самий простір пам’яті, але він все одно може скопіювати весь файл у цей простір. Зокрема, коли копії робляться з / в локальні файлові системи, rsync передбачає цей --whole-fileваріант. Але коли він знаходиться в мережевих системах з іншого боку, він передбачає такий --no-whole-fileваріант.