In the unrelated linked discussion, --whole-file was recommended on the basis that it may be more efficient to write a contiguous file to a flash drive, rather than overwrite just the parts that have changed. That was only an issue because the questioner was also using --inplace. By default, rsync writes each complete new file under a temporary name first anyway.
Note that the main purpose of delta-xfers is not to improve storage performance but to reduce network traffic. In your case both the sending and receiving rsync processes are running on the Pi4, so there is no network bottleneck between them at all.
If you write data to a filesystem faster than the storage can handle, you will hit a performance wall. You do not want to make the rsync faster, you want to slow it down so it does not affect the rest of the system so much.
So you might try rsync --bwlimit= (but this is really intended to limit "network" utilization), or ionice -c3 rsync … Or break your big rsync into smaller pieces and run them at different times.
You have not addressed the comment about whether the umount that appeared to be running might be the real problem.
Note that the main purpose of delta-xfers is not to improve storage performance but to reduce network traffic. In your case both the sending and receiving rsync processes are running on the Pi4, so there is no network bottleneck between them at all.
If you write data to a filesystem faster than the storage can handle, you will hit a performance wall. You do not want to make the rsync faster, you want to slow it down so it does not affect the rest of the system so much.
So you might try rsync --bwlimit= (but this is really intended to limit "network" utilization), or ionice -c3 rsync … Or break your big rsync into smaller pieces and run them at different times.
You have not addressed the comment about whether the umount that appeared to be running might be the real problem.
Statistics: Posted by jojopi — Mon Feb 24, 2025 1:18 am