I create a new thread, because the issue is not really the same, but i copy
here the thread that made me jump into the list.
My issue is not really that it waits before starting copying, but a general
performance issue, specially when there are multiple rsync running at the same
time.
Here is
When rsync has a lot of files to look through but not many to actually
transfer most of the work will be gathering information from the stat()
function call. You can simulate just the stat call with: find /path
-type f -ls > /dev/null
You can run one then a few of those to see if your storage has
most likely, you ovestrain your NAS with disk random IOPs. furthermore, iSCSI is an additional throttle here, making things worse.
your issue is probably centered around metadata reads/latency...
have a look on IO-Wait on the server/nas side...
regards
roland
Gesendet: Mittwoch
Em ter, 20 de mar de 2018 19:26, Kevin Korb escreveu:
> It creates the directories as it needs them. If you want to watch it
> looking through files it doesn't need to copy you can add -ii (see
> --itemize-changes for what the output means).
>
Nice, this should help debugging
>
> On 03/20/2018
https://bugzilla.samba.org/show_bug.cgi?id=8682
--- Comment #4 from Christian Kujau ---
If this ever gets implemented: instead of (interactively) pressing a key to
interrupt the current transfer of a particular object, I'd like it to also
react to a signal (e.g. SIGUSR1) that can be sent to rsync
