bscp is slower than rsync

[adamgoryachev]

I'm copying a bunch of LV's from the local machine to a remote machine. My old script did the following:

1. Get the name of the next LV
2. Snapshot the LV
3. Calculate the number of "chunks" in the LV (chunksize = 1G)
   3a) Use dd to read the chunk from the snapshot, and write to a ramdrive on the local system
   3b) Use ssh to the remote system, and use dd to read the chunk from the remote LV to a ramdrive on the remote
   3c) Depending on time of day and day of week, either set the rate to 1.5m or unlimited
   3d) Use rsync with the rate to update the remote copy of the "chunk"
   3e) Use dd to write the remote chunk back to the LV
   3f) Delete the local chunk copy
   3g) loop back to 3a for the next chunk
4. Delete the snapshot

The "new" script seemed like a much better solution, since it would save steps 3a, 3b, and 3e which should all be somewhat "slow" compared to just reading, and writing the changes. It simply replaced all of step 3 with bscp to copy the snapshot to the remote.

The old script took approx 36 hours to complete (max 36 hours, min 29.5 hours, avg 33.8 hours over 10 runs) , and my hope was that bscp would help to reduce it to closer to 24 hours (or less, since it no longer sets a bwlimit during the sync copy). However, it is taking significantly longer, the current run has taken over 72 hours, and is still not complete yet. This isn't the first run, just I don't have the logs from the previous runs.
Can anyone advise if they have seen bscp as being (significantly) less efficient than rsync, or am I doing something wrong? Is there an alternative?

For reference, the maximum speed of the connection is 20Mbps, and the total size of all LV's being copied is 5.4TB.

[adamgoryachev]

Please see some additional details from the now completed backup:
Total run time, approx 95 hours (so more than double the rsync time).
2019-03-29 11:48:01 OK Starting VM Imaging process
2019-04-02 10:26:43 OK Image Sync Process Complete
Here is the bscp output for each of the LV's:
in=55704368 out=3931394722 size=182531915776 speedup=45.78
in=22553648 out=4951455994 size=73903636480 speedup=14.86
in=9831728 out=4048521850 size=32216449024 speedup=7.94
in=85196848 out=61157336770 size=279172874240 speedup=4.56
in=3276848 out=59 size=10737418240 speedup=3276.69
in=6480688 out=58 size=21235761152 speedup=3276.75
in=16384048 out=8415849656 size=53687091200 speedup=6.37
in=351930928 out=44504507143 size=1153207107584 speedup=25.71
in=16384048 out=7263586139 size=53687091200 speedup=7.37
in=16384048 out=65599 size=53687091200 speedup=3263.72
in=94031408 out=83130831680 size=308121960448 speedup=3.70
in=49152048 out=65602 size=161061273600 speedup=3272.43
in=32769328 out=2766022397 size=107378376704 speedup=38.37
in=9831728 out=65601 size=32216449024 speedup=3255.06
in=32768048 out=3261731677 size=107374182400 speedup=32.59
in=29491248 out=702107391 size=96636764160 speedup=132.09
in=49152048 out=62929122178 size=161061273600 speedup=2.56
in=6480688 out=65601 size=21235761152 speedup=3243.94
in=16385328 out=5907939589 size=53691285504 speedup=9.06
in=114690608 out=15304392974 size=375818027008 speedup=24.37
in=632265008 out=117613202368 size=2071805820928 speedup=17.52
in=41943088 out=23601804566 size=137438953472 speedup=5.81
in=41943088 out=14384482934 size=137438953472 speedup=9.53
in=41943088 out=15946199822 size=137438953472 speedup=8.60

If there is any additional data that would be helpful, please let me know.

[vog]

This is really strange and I have no explanation for this. When I measured years ago, the results for Rsync were very bad, which is why I created Bscp in the first place.

[vog]

To anyone involved in this issue, please see #16 "Future of bscp".

[vog]

Meanwhile, Bscp improved quite a lot, hopefully solving the observed performance issues along the way.

@adamgoryachev Would you mind repeating your measurements with the latest version of Bscp?

[adamgoryachev]

Unfortunately I'm no longer working in that environment, and no longer using rsync/bscp for replication. You can probably close this issue unless someone else is having the same problem.
Now I re read this, I wish I had kept my script, it was at least interesting in the way it solved the issue