<div dir="ltr"><div>More notes about <a href="https://github.com/dop251/diskrsync">diskrsync</a> :</div><div><br></div><div>(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.)<br></div><div><br></div><div>(1) Effectively, inherently, and non-optionally, diskrsync has rsync's --inplace feature. IOW, diskrsync doesn't transfer data redundantly.  Good!<br></div><div><br></div><div>(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. :(</div><div><br></div><div>(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. :(<br></div><div><br></div><div>(4) The "nice" command doesn't work at diskrsync launch time to control CPU usage, but renice works on an already-running diskrsync process.  <br></div><div><br></div><div>(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.<br></div><div><br></div><div>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. <br></div><div><br></div></div>