Rsync bardzo wolno

Właśnie skonfigurowałem serwer Debiana do tworzenia kopii zapasowych komputerów z systemem Windows. Obecnie testuję różne metody, w tym: rsync (za pomocą Deltacopy w systemie Windows), SMB za pośrednictwem Samby i scp . Obecnie rsync (bez SSH i bez kompresji) i scp potrzebują około 16 minut na gigabitową sieć LAN do transferu plików o pojemności 9 GB. Jednak SMB zajmuje tylko kilka minut. Dlaczego rsync jest szczególnie wolny? Czuję, że mogę być nieporozumieniem, skąd biorą się prawdziwe zalety rsync, czyli przeniesienie tylko zmienionych bitów. Nadal jednak uważam, że nie wyjaśnia to początkowej prędkości wolnego transferu i muszę robić coś złego.

We wszystkich przypadkach przenoszę się do udziału Samby na moim Linuksie.

problem polega na tym, że rsync wykorzystuje czas modyfikacji i rozmiar pliku jako szybkie odniesienie do oceny, czy plik się zmienił. Istnieje bardziej szczegółowy i precyzyjny sposób sprawdzenia, czy pliki się zmieniły, a rsync również to obsługuje, jednak jeśli czas modyfikacji i rozmiar pliku odłożą się w pierwszej kolejności, te „bardziej szczegółowe” kontrole są pomijane, a następnie rsync przyjmuje plik uległo zmianie, dlatego próbuje skopiować cały plik.

W szczególności, gdy w środowisku heterogenicznym (Windows + Linux, ...) i gdy nie pracuje się na lokalnych systemach plików (np. Przy użyciu montaży / udziałów SMB lub innych protokołów), istnieje niewielka możliwość, że czasy modyfikacji nie zostaną poprawnie przekazane między źródłem rsync a jego miejscem docelowym.

Może być tak, że czasy modyfikacji są zaokrąglane lub w inny sposób zmieniane przez używany system operacyjny i / lub protokół sieciowy, a zatem wyglądają na inne (nawet jeśli tylko nieznacznie, nawet jeśli lokalny system plików ma „poprawny” mtime).

Sprawdź, czy może to być przypadek, czy nie, i przetestuj go za pomocą wiersza poleceń (jeśli to możliwe) i programów narzędziowych, takich jak „stat” (Linux) lub, jeśli jest to absolutnie konieczne, mini-programów perl / python, które wyświetlają dokładny czas modyfikacji propagowany przez właściwości systemu operacyjnego i lokalnego systemu plików (ostatecznie omijając wszelkie protokoły sieciowe, takie jak Samba).

Przykładowe dane wyjściowe narzędzia „stat” w systemie UNIX:

$ stat somefile.txt 
  File: `somefile.txt'
  Size: 1014        Blocks: 8          IO Block: 4096   regular file
Device: 805h/2053d  Inode: 1448800     Links: 1
Access: (0644/-rw-r--r--)  Uid: (    0/    root)   Gid: (    0/    root)
Access: 2012-07-21 17:20:33.548997182 +0530
Modify: 2011-08-16 23:27:19.648480473 +0530
Change: 2011-08-16 23:27:19.648480473 +0530

Nie może być tak, że polecenia rsync konsekwentnie trwają „16 minut”. To nie ma sensu. Zwykle rsyncs stają się coraz szybsze, im mniejsze są różnice przed i po każdym uruchomieniu. Tylko SCP będzie podjąć stałą czasu za każdym razem gdy go uruchomić, w zależności od ilości kopii. Więc ten fakt, plus fakt, że już wykluczyłeś kompresję i szyfrowanie (ssh), może sprawić, że założę, że coś się dzieje z porównaniem czasu modyfikacji.

Sam miałem ten przypadek sam z zamontowaniami Samby z mojego serwera Synology NAS. Jednak niezależnie od tego, czy tak jest w przypadku Ciebie, czy nie, mam nadzieję, że wkrótce znajdziesz prawdziwą przyczynę swojego problemu.

Baw się dobrze.