rsync vs cp na Synology NAS

Po tym, jak byłem rozczarowany wydajnością zewnętrznego napędu USB z moim Synology DS251j, przeprowadziłem kilka testów transferu na powłoce.

Co ciekawe, stwierdziłem, że skopiowanie pliku testowego 1 GB zajmuje trzy razy dłużej przy użyciu rsyncniż za pomocą prostej cpkomendy.

Nie mogłem potwierdzić tego zachowania w stacjonarnym systemie Linux. Czy ktoś miał podobne doświadczenie? Czy coś jest nie tak z rsyncDS?

Testcript:

#!/bin/bash
sync
echo `date +%M:%S`
cp /volume1/a.tmp /volumeUSB1/usbshare
sync
echo `date +%M%S`
rsync /volume1/b.tmp /volumeUSB1/usbshare
sync
echo `date +%M:%S`

Pliki a.tmpi b.tmpkażdy ma 1 GB, volume1jest punktem montowania dla dysku wewnętrznego /volumeUSB1/usbsharejest punktem montowania dysku USB 3.

Kolejnym potwierdzeniem tego zachowania jest fakt, że mogłem z łatwością wykonać kopię zapasową całego dysku przez noc, cpgdy nie było to możliwe rsync.

nas rsync synology

— Bruno
źródło

Zakładam te same punkty początkowy i docelowy oraz że nie wykonałeś po kolei operacji (aby uniknąć pobrania wersji gotówkowej); czy możesz edytować swoje pytanie, dodając wiersz poleceń podany przy pomocy rsync? (Nawet by zrozumieć, czy to pisanie czy czytanie z dysku ...)

— Hastur

Ile procesora używasz, gdy rsync vs zwykły cp? IIRC ma dwurdzeniowy procesor Marvell Armada 375 o częstotliwości 800 MHz).

— Hennes,

Być może procesor jest tutaj wąskim gardłem. Przeprowadziłem testy z rsync i dużymi plikami, a obciążenie procesora dostarczone przez interfejs WWW przekroczyło 80%. Dowiedziałem się również, że użycie opcji Wwydaje się, że przesyłanie całych plików nieco poprawia wydajność - nawet jeśli jest tylko jeden plik, który nie jest obecny w celu.

— Bruno,

Można się spodziewać , że rsync będzie wolniejszy niż cp dla pierwszej kopii, ponieważ robi to nieco więcej „do” wracania i „przewijania”. Być może nie potrwa to jednak 3 razy.

Można oczekiwać , że rsync będzie działał wolniej przy kolejnych kopiach „aktualizacji”, jeśli zostanie użyta opcja -c, a suma kontrolna odczytu i kontroli jest kosztowną operacją na komputerze docelowym (wolny dysk, wolny procesor lub niewystarczająca pamięć). Podobnie może być powolne bez -c, jeśli są duże pliki i wiele z nich jest zmienionych.

Jeśli zapomniałeś użyć -t zarówno podczas pierwszego, jak i kolejnego uruchomienia, spowodowałoby to również, że rsync musiałby odczytać i zsumować cały plik.

Zasadniczo, za każdym razem, gdy rsync musi napisać wszystko (lub prawie tak), cp wygra, więc powinieneś uważać, aby ustawić opcje tak, aby mógł wykonać jak najmniej pracy.

Jeśli rsync z całkowicie niezmienionymi plikami nie zostanie ukończony w czasie potrzebnym do „stat” każdego pliku w drzewie (na wolniejszym dysku), oznacza to, że zrobiłeś coś złego.

Inne problemy z używaniem rsync na wolnych komputerach to koszty kompresji i szyfrowania. Powinieneś wyłączyć te opcje (lub ustawić je tak, aby pasowały do tego, czego używasz dla cp) zarówno w rsync, jak i SSH, w miarę możliwości. Oczywiście SSH nie całkowicie wyłącza szyfrowania, ale możesz dostosować szyfrowanie w ~/.ssh/config(na drugiej maszynie); oto, czego używam do mojej Synology:

Host diskstation
    Ciphers arcfour256
    macs hmac-md5-96

gdzie „stacja dyskowa” to adres IP twojego serwera NAS.

— ams
źródło