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
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.