Rsync of LVM Snapshots copies whole file

Paul Slootman paul+rsync at
Thu Aug 21 08:43:20 GMT 2008

On Wed 20 Aug 2008, Peter P GMX wrote:
> here is the status of the transfer.
> If I understand it right, about 3% of the data was changed (literal data  
> against matched data). It took about 1h40min to transfer ~250MB of data.

The searching for matching data blocks is apparently taking a lot of
time. However, it is clear that not the whole file is being transferred,
the speedup is reported as 188.01 while a whole file transfer would be

> But to be honest, I do not get a real clue out of this status report.
> E.g. Laptop_D_10GB.vdi takes around 25 minutes to be transferred with  
> 6,74MBytes/sec. If I divide 10G by 6,74MBytes/sec (for a complete file  
> transfer) I end up at 40 minutes. So almost half of the complete data  
> transfer time of this volume is needed, although this drive is rather  
> passive and there were almost no changes on the drive between the last  
> sync. (The machines are a AMD X2 3800 on one originating side and a Atom  
> 1,6GHz on the destination side, Atom pulls from AMDs side).

When updating files, rsync reads the source data, reads the existing
target data, and creates a new copy of the target data. If the disk on
the destination is not so fast, the seeking to and from the old and new
copy can impact performance. In that case using --whole-file could
actually speed up the process... which is exactly the reverse of what
you thought at the beginning :-)

If you don't mind that the destination copy is invalid for some time
(e.g. if it's just used for backup), _and_ you know that data won't be
moved, only updated at random places, you might try --inplace. That way
the existing copy is updated, instead of copying the data to a new file.


More information about the rsync mailing list