Bug 7337 - sparse files not equally sparse on destination
sparse files not equally sparse on destination
Product: rsync
Classification: Unclassified
Component: core
Other Linux
: P3 normal
: ---
Assigned To: Wayne Davison
Rsync QA Contact
Depends on:
  Show dependency treegraph
Reported: 2010-04-08 09:38 UTC by Brian J. Murrell
Modified: 2010-11-06 12:18 UTC (History)
1 user (show)

See Also:


Note You need to log in before you can comment on or make changes to this bug.
Description Brian J. Murrell 2010-04-08 09:38:33 UTC
If I create a 0 block sparse file and then rsync it, it's not 0 blocks on the copy.  Here's a reproducer:

$ rsync --version
rsync  version 3.0.7  protocol version 30
Copyright (C) 1996-2009 by Andrew Tridgell, Wayne Davison, and others.
Web site: http://rsync.samba.org/
    64-bit files, 64-bit inums, 32-bit timestamps, 64-bit long ints,
    socketpairs, hardlinks, symlinks, IPv6, batchfiles, inplace,
    append, ACLs, xattrs, iconv, symtimes

rsync comes with ABSOLUTELY NO WARRANTY.  This is free software, and you
are welcome to redistribute it under certain conditions.  See the GNU
General Public Licence for details.
$ dd if=/dev/zero of=/tmp/sparse_file bs=1M count=0 seek=5
0+0 records in
0+0 records out
0 bytes (0 B) copied, 0.000125157 s, 0.0 kB/s
$ ls -ls /tmp/sparse_file
0 -rw-r--r-- 1 brian brian 5242880 2010-04-08 10:33 /tmp/sparse_file
$ rsync --sparse /tmp/sparse_file /var/tmp
$ ls -ls /var/tmp/sparse_file 
12 -rw-r--r-- 1 brian brian 5242880 2010-04-08 10:34 /var/tmp/sparse_file

Notice the source file is 0 blocks long and the destination is 12 blocks long.

Gnutar on the other hand makes the destination as sparse as the source:

$ tar CcSvf /tmp - sparse_file | tar Cxvf /var/tmp/ -
$ ls -ls /var/tmp/sparse_file 
0 -rw-r--r-- 1 brian brian 5242880 2010-04-08 10:33 /var/tmp/sparse_file
Comment 1 Wayne Davison 2010-04-24 13:20:31 UTC
Rsync currently writes out a 0-byte into the final byte of the file when a file is sparse clear through to the end.  We should probably change that to use ftruncate() (when available) instead.  I'll give that a try soon, unless someone beats me to the punch.
Comment 2 Ildar Muyukov 2010-11-05 14:42:30 UTC
You might want to use "du" to see how much space a file spends. It is 0 for both source and destination files.

Or did I miss something?
Comment 3 Wayne Davison 2010-11-06 12:18:21 UTC
As long as the extra space was caused by the final block getting allocated when it shouldn't have been, this should now be fixed in git.  If the file's real blocksize vs its rsync blocksize caused some unallocated blocks to not get found, that is not something that can be easily fixed.