Certainly. The lftp mirror subsystem allows you to break up batches of files, or even a single file using p-get into multiple streams. Rsync can't do that. Rsync also doesn't work within a chroot environment, whereas lftp does. The exception is if you use native rsync, which means you are not encrypting the stream. You then get chroot, but not privacy.
CPU overhead isn't really a limiting factor these days, assuming your computer is less than a decade old.
With sftp chroot, I can let people upload files without executing files, while preventing eavesdropping. rsync does not support TLS without complex stunnel wrappers on each side.
> The lftp mirror subsystem allows you to break up batches of files, or even a single file using p-get into multiple streams.
I do not see any particular benefit from that... Network reliability is still a bit needed or you still have to restart...
On restricting rsync on the other end there are many guide so again I do not see much benefit and that's not true that you can't encrypt the transfer otherwise with classic ssh transport this is an example
Try lftp some time. There is a working example on the link I provided. It is much easier for people to set up than cryptcat / ncat / stunnel. I have found that people will follow the least path of resistance.
What I suspect you will find is that where a single rsync stream might reach a couple hundred mb/s, lftp can saturate the link if you wish. At least, that is what most people find that try it out.
I have used in the past, a distant past, both for ftp, sftp and ftps and sincerely I'm not much attracted...
On setup cryptcat and ncat require almost ZERO setup, and you still need to have ssh on the over side unless you are restricted by some common crappy webui so...
Also, I see no reason to saturate the link apart of try to milk more performance at the expense of all others, servers and network hardware are not there to be abused but to be used... It's the same story with people that abuse http range to start multiple downloads of a single big file trying to milk a bit of performance...
rsync performance are not much rsync related, they depend on network, encryption and compression you use, disk I/O, ... per se it's pretty efficient. Certainly if you can incremental send a zfs snap via mbuffer is far more efficient but that's far more efficient than any kind of logic file transfer...
CPU overhead isn't really a limiting factor these days, assuming your computer is less than a decade old.
With sftp chroot, I can let people upload files without executing files, while preventing eavesdropping. rsync does not support TLS without complex stunnel wrappers on each side.