It really feels like rsync should have a multi-path setting that would have sped this up across multiple links (but doesn't because noone has made it yet).
You could just run multiple rsync processes using different src and dest paths to achieve multiple copy streams. Anyway this would not be likely much faster if rsync is run over encrypted SSH due to CPU performance, compared to unencrypted SMB.
I took a look into it mostly to satisfy my curiosity. The AES-NI chip on the J4125 in the Synology DS1520 hits 5Gbit/s transfer when using 4 cores (AES-256-GCM). So technically this it would be possible to saturate its 4 ethernet ports (or at least the encryption wouldn't be the bottleneck). You could back this down to 128 or drop the encryption altogether on an network that you own like this reasonably.
My guess is the actual bottleneck would be directory traversal and metadata stuff - i.e. trying to keep the pipe full, not saturation effects.
Yeah I know on src/dest. I've done this sort of approach countless times in various technologies in the past 40 or so years, but that always puts the mechanism for checking things in onus of the human rather than having that one command that does it all right.
Anyway, not a slight on rsync in the slightest - it doesn't have this probably because no-one realistically actually needs it most of the time.
Comments
It really feels like rsync should have a multi-path setting that would have sped this up across multiple links (but doesn't because noone has made it yet).
I use bbcp for that, it supports multiple streams.
https://docs.nersc.gov/services/bbcp/
You could just run multiple rsync processes using different src and dest paths to achieve multiple copy streams. Anyway this would not be likely much faster if rsync is run over encrypted SSH due to CPU performance, compared to unencrypted SMB.
I took a look into it mostly to satisfy my curiosity. The AES-NI chip on the J4125 in the Synology DS1520 hits 5Gbit/s transfer when using 4 cores (AES-256-GCM). So technically this it would be possible to saturate its 4 ethernet ports (or at least the encryption wouldn't be the bottleneck). You could back this down to 128 or drop the encryption altogether on an network that you own like this reasonably.
My guess is the actual bottleneck would be directory traversal and metadata stuff - i.e. trying to keep the pipe full, not saturation effects.
Yeah I know on src/dest. I've done this sort of approach countless times in various technologies in the past 40 or so years, but that always puts the mechanism for checking things in onus of the human rather than having that one command that does it all right.
Anyway, not a slight on rsync in the slightest - it doesn't have this probably because no-one realistically actually needs it most of the time.