I know about the -S option, but to my understanding this still does an awful lot of 0-memory-handling; it simply seeks over 0s on the receiving end. # touch sparsefile # /root/truncate sparsefile 8589934592 # time /tmp/rsync -S sparsefile sparsefile2 real 0m59.651s user 1m13.718s sys 0m34.412s # ls -lh sparsefile2 -rw-r--r-- 1 root root 8.0G Sep 24 14:03 sparsefile2 # du -h sparsefile2 20K sparsefile2 so 1 minute to transfer 20k (hm, why not 0k, but anyway) Would it be possible to do the 0-detection on the sender, and essentially just send seeks to the receiver? Would skipping checksums for large swaths of 0s speed things up? Or even, use fiemap to obtain file mapping and only read/transfer instantiated block ranges? Not sure if this fits into how rsync is designed, but it'd be a very nice feature if possible. This would probably have a nice usecase for moving guest vm images around ...
This is covered by rsync bug (don't link) #5801 except for the fiemap part.
Matt, thanks. I really think this would be hugely useful for transferring filesystem images for xample (whether for analysis, vm shuffling, etc...) -Eric
This package has changed ownership in the Fedora Package Database. Reassigning to the new owner of this component.
The fiemap part is now filed upstream: https://bugzilla.samba.org/show_bug.cgi?id=8918
5 years later it's pretty clear that asking Fedora to fix this was the wrong way to go. ;) No need to have a bug cluttering things up if it's never going to get touched.
What would be a feasible way to proceed?
I suppose I should bring it up upstream...
There are already filled upstream bugzillas for better sparse file support - https://bugzilla.samba.org/show_bug.cgi?id=8918 https://bugzilla.samba.org/show_bug.cgi?id=5801 https://bugzilla.samba.org/show_bug.cgi?id=7854