On Wed 15 May 2024, Graham Leggett via rsync wrote: > > Then we check the disk underneath rsync: > > [root@arnie images]# dd if=/dev/urandom of=random.img count=1024 bs=10M > status=progress > 1604321280 bytes (1.6 GB, 1.5 GiB) copied, 16 s, 100 MB/s^C > 159+0 records in > 159+0 records out > 1667235840 bytes (1.7 GB, 1.6 GiB) copied, 16.7261 s, 99.7 MB/s. <---- fast > enough
I would try this again with the block size that rsync is using, which will be way less than 10MB. It could be that the VM is limited in the number of IOPS, which is slowing rsync down. If that is the problem, using --whole-file might help as that stops rsync "wasting" IOPS on reading the existing files, and may help in de IO block size. Using 'top' while rsync is running may help to see if rsync is IO bound, the "wa" (wait IO) column will have a large percentage then. You can also run strace to profile rsync to see where most wall clock time is spent: strace -w -c You'll have to do this on each rsync process. Paul -- Please use reply-all for most replies to avoid omitting the mailing list. To unsubscribe or change options: https://lists.samba.org/mailman/listinfo/rsync Before posting, read: http://www.catb.org/~esr/faqs/smart-questions.html
