Dlaczego rsync nie używa transferu delta dla plików lokalnych?

25

Mam duży obraz ISO, który jest obecnie pobierany przez klienta torrenta z włączoną rezerwacją miejsca: oznacza to, że rozmiar pliku się nie zmienia, a niektóre porcje w (4 Mib) ciągle się zmieniają z powodu pobierania.

Przy 90% pobierania robię początkową synchronizację, aby zaoszczędzić czas później:

$ rsync -Ph DVD.iso / media / another-hdd /
wysyłanie przyrostowej listy plików

DVD.iso
       2,60G 100% 40,23 MB / s 0:01:01 (xfer # 1, do sprawdzenia = 0/1)

wysłane 2,60G bajtów odebrane 73 bajty 34,59M bajtów / sek
całkowity rozmiar to 2.60G przyspieszenie to 1.00

Następnie, gdy plik zostanie w pełni pobrany, ponownie synchronizuję:

total size is 2.60G   speedup is 1.00

Przyspieszenie = 1 mówi, że transfer delta nie był używany, chociaż 90% pliku się nie zmieniło, katalog docelowy znajduje się na innym FS, a kopiowanie zajmuje kilka minut. Dlaczego nie próbuje przyspieszyć transferu ?! Jak mogę wymusić rsyncużycie transferu delta?

kolypto
źródło
6
To, co robisz, nie ma sensu. Celem rsync jest przyspieszenie przesyłania plików przez sieć, a nie lokalnie. Aby znaleźć różnice, musi odczytać zarówno źródło, jak i miejsce docelowe. W czasie potrzebnym do lokalnego odczytania miejsca docelowego w celu znalezienia różnic możesz równie dobrze zrobić normalną kopię. Po prostu pobierz plik do miejsca docelowego zamiast go kopiować.
psusi
1
Więc po prostu nie używa delta-xfer, ponieważ działając lokalnie, szybsze jest kopiowanie niż obliczanie skrótów? Jeśli tak - opublikuj odpowiedź plz :)
kolypto 17.01.11
9
W pewnych okolicznościach odczyt może być szybszy niż zapis na dysku lokalnym. Może także zmniejszyć zużycie dysku SSD. To z pewnością ważne pytanie, a odpowiedź jest dla mnie bardzo cenna.
HRJ
2
@psusi oprócz powyższego komentarza HRJ, rozważ także przypadek, gdy plik docelowy został ponownie połączony (np. na btrfs lub ocfs2). Minimalizacja zapisów podczas synchronizacji może mieć ogromną różnicę w ogólnym zużyciu miejsca.

Odpowiedzi:

20

Według strony man , psusi ma rację:

-W, --whole-file : Transfer może być szybszy, jeśli ta opcja jest używana, gdy przepustowość między maszyną źródłową i docelową jest większa niż przepustowość do dysku (szczególnie, gdy „dysk” jest w rzeczywistości sieciowym systemem plików). Jest to ustawienie domyślne, gdy zarówno źródło, jak i miejsce docelowe są określone jako ścieżki lokalne, ale tylko wtedy, gdy nie obowiązuje opcja zapisu wsadowego.

liganic
źródło
10
Och dziękuje! Zepsułem tę linię :) Aby włączyć delta-trasfer, użyj-no-W
kolypto
1
W moim systemie -no-Wnie działa tylko długa opcja -no-whole-file. Powodem, dla którego potrzebuję tego przełącznika jest to, że konfiguruję kopię zapasową i mam duże pliki (np. Obrazy), które nie mają tego samego czasu modyfikacji. Jest DUŻO szybszy, przyspieszenie to 163,26, aby zsynchronizować te pliki przy użyciu transferu delta na moim lokalnym systemie plików.
Jesse the Wind Wanderer
6
@JessetheWindWanderer, długą opcją jest --no-whole-file(proszę zwrócić uwagę na podwójne --na początku).
Eddie C.
Dzięki Eddie C. Zredagowałbym mój komentarz, gdybym mógł wymyślić, jak :-(
Jesse the Wind Wanderer
17

Prosta odpowiedź na to pytanie brzmi:

Użyj --no-Wflagi, aby wymusić kompresję delta, niezależnie od tego, czy jest ona lokalna czy zdalna.

Aktualizacja: Wygląda na to, że w tej historii jest coś więcej. delta compressionWydaje się być aktywna tylko między proces nadawania i odbierania rsync. Podczas wysyłania pliku do systemu plików rsyncmoże nadal zapisywać cały plik (pliki), nawet przy włączonej kompresji delta.

Zobacz dochodzenie „Wakan Tanki” tutaj .

HRJ
źródło
2
--no-Wzawsze przesyłaj cały plik w moim przypadku. Proszę sprawdzić unix.stackexchange.com/questions/291156/…
Wakan Tanka
@WakanTanka To ciekawe! Zaktualizowałem swoją odpowiedź.
HRJ,
3

Domyślnie rsync najpierw tworzy nową kopię pliku docelowego, a następnie zastępuje ją z różnych powodów bezpieczeństwa. Możesz to zmienić, podając --inplacewraz z --no-whole-file. To mówi rsync, aby dokonała edycji na miejscu pliku docelowego, akceptując różne ryzyka (zwykle niewielkie w tej sytuacji), jak udokumentowano na stronie man.

kartik_subbarao
źródło
0

Domyślnie rsynctworzy kopię pliku w miejscu docelowym, a następnie atomowo zastępuje oryginał nową kopią. Odbywa się to ze względów bezpieczeństwa. To, czego szukasz, to --inplaceopcja, która spowoduje rsyncmodyfikację tylko tych części pliku docelowego, które zmieniły się względem źródła.

W przypadku użycia PO zalecam również wyłączenie wstępnej alokacji, aby zsynchronizować rzadką kopię, która będzie znacznie szybsza. W przypadku pobierania nie martw się o fragmentację, chyba że używasz bardzo starego systemu plików, takiego jak VFAT. W szczególności pliki multimedialne nie są odczytywane przy maksymalnej wydajności nośników pamięci, więc ich defragmentacja to zmarnowany wysiłek.

Aby rzadko kopiować katalog pobierania do woluminu docelowego, polecam te flagi i operacje w następującej kolejności:

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

Pierwszy przebieg rzadko kopiuje nowe pliki do miejsca docelowego. Drugi przebieg aktualizuje istniejące pliki w miejscu, kopiując tylko zmiany

Ponieważ wykonuje rzadkie i lokalne kopie delta, możesz uruchamiać to wielokrotnie, nie ponosząc przy tym dużo dodatkowego IO. Nawet jeśli masz jednocześnie uruchomionych 20 torrentów, nie zwiększy to zapisu w miejscu docelowym ani nie zniszczy woluminów źródłowych / docelowych.

Wil
źródło
Co masz tutaj na myśli mówiąc „rzadko”, Wil? O ile mi wiadomo, to tak naprawdę nie odzwierciedla faktycznego znaczenia tego słowa.
Julius
@Julius: oznacza dokładnie to, co sugeruje - skopiuj pliki z pełną obsługą alokacji rzadkich, więc na przykład filmy HDR 40 GB nie zajmą więcej miejsca w miejscu docelowym niż w źródle. To samo z obrazami dysków VirtualBox. Jak wspomniano, PO będzie musiał wyłączyć wstępny przydział, aby to zadziałało.
Wil