More notes about diskrsync <https://github.com/dop251/diskrsync> :
(0) It seems to work well and efficiently. The README.md now explains how
to install it and it's a lot easier than the script I included in my last
note would seem to indicate. (I didn't and still don't know Go.)
(1) Effectively, inherently, and non-optionally, diskrsync has rsync's
--inplace feature. IOW, diskrsync doesn't transfer data redundantly. Good!
(2) Diskrsync has no bandwidth limiting feature (--bwlimit), nor can the
"trickle" command be used with it in order to limit IP bandwidth
usage;
trickle simply has no effect. Reportedly this is because the Go language
(the "golang" package in Debian-land) uses system calls directly
rather
than via libc. :(
(3) Same goes for iotop. Iotop has no effect at launch time, and it can't
re-iotop (reclassify the i/o priorities of) already-running diskrsync
processes, either. :(
(4) The "nice" command doesn't work at diskrsync launch time to
control CPU
usage, but renice works on an already-running diskrsync process.
(5) Diskrsync provides no convenient way to affect the processing niceness
or i/o niceness etc. of the process launched at the remote host, as there
is with rsync's --rsync-path feature.
To summarize: while diskrsync is looking like the most suitable solution
known to us, it would still be more convenient, gentler, kinder, and wiser
if the ability to transfer raw block device content were added to rsync.
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.samba.org/pipermail/rsync/attachments/20190102/45a451a2/attachment.html>