Komputer pełniący rolę serwera pracuje pod kontrolą systemu OpenSolaris.
Logując się na serwer zauważyłem, że bardzo mało danych jest wysyłanych przez sieć, natomiast dysk jest używany w 100%:

Widać, że dysk 'cmdk1' ma sporo operacji odczytu.
Za pomocą skryptu DTrace 'rwbytype', znajdującego się w pakiecie DTrace Toolkit (DTT) sprawdziłem jakie procesy używają I/O:

Kolejny skrypt z DTT 'pfilestat' pokaże statystyki otwartych plików danego procesu:
# /opt/DTT/Proc/pfilestat 5981

Widać, że proces odczytuje sporo z deskryptora pliku nr 0.
Aby dowiedzieć się więcej o tym pliku wystarczy użyć komendy 'pfiles' z numerem PID:
# pfiles 5981

Teraz już wiadomo dlaczego rsync 'zatrzymał' się na chwilę z kopiowaniem danych.
W tym przypadku porównuje sumy kontrolne źródłowego i docelowego pliku, ponieważ plik został zmodyfikowany od ostatniego kopiowania.
Porównywany plik jest obrazem dysku wirtualnej maszyny VirtualBox'a i zajmuje 13GB, dlatego też ta operacja zatrzymała 'progress' jaki pokazuje rsync.
Aby przyśpieszyć kopiowanie plików usunąłem ten plik z docelowego miejsca, jednocześnie mając jego kopię w snapshotach ZFS.