6

I have a sparse raw qemu image that I want to transfer to another server. qemu-img info gives me:

image: sparse.img
file format: raw
virtual size: 50G
disk size: 16G

I transfer it with:

rsync -azhP --sparse origin:/path/to/img/sparse.img .

Now, on the destination server I have:

image: sparse.img
file format: raw
virtual size: 50G
disk size: 40G

However, after running virt-sparsify again on the copied image, I get this:

image: sparse.img
file format: raw
virtual size: 50G
disk size: 16G

Both servers are running CentOS 7.2 on a XFS filesystem. So what happened?

Update:

After some more research, I found several posts indicating that rsync doesn't handle sparse files well, and that it's better to use a different tool, such as tar, to transfer sparse files.

You could follow up the tar transfer with rsync --inplace, to make sure the file was transferred wtihout errors, as explained here.

Another solution that was proposed was creating an empty sparse file of the same size on the destination, and then using rsync --inplace to transfer the actual data.

I didn't write this as a solution, because it doesn't really explain why rsync --sparse is behaving this way.

  • Did you transfer it a first time without --sparse and then repeat the process to try and turn the full file into a sparse one? – roaima Dec 16 '16 at 0:14
  • No. Just one transfer. – orodbhen Dec 16 '16 at 0:15
  • That's certainly not expected behaviour. Your command looks good to me. What version of rsync (use rsync --version) – roaima Dec 16 '16 at 0:16
  • The rsync version is 3.0.9 protocol version 30. I have noticed a few instances where Redhat has made strange alterations to the default behavior of a package, but I think that's unlikely in this case. – orodbhen Dec 16 '16 at 14:47
  • If xfs is continually pre-allocating space at eof as the file grows, perhaps you can try asking rsync to start with a sparse file of the right size with rsync --preallocate – meuh Dec 16 '16 at 16:29
2

I bet this is due to FS disparities between the source and the destination.

Let me elaborate with an example. Sparse files are files whose empty blocks (i.e. full of 0) are not allocated on the disk. The smaller the block size on the FS, the likelier such a block can be found. So, your issue may be due to a block size being bigger on the destination than on the source.

There may be other XFS parameters that I don't know.

See also this question on ServerFault

  • I get the same result when copying the image locally from one partition to another, both XFS. Could this still apply in that situation? It seems that the block size would have to be the same for partitions on the same HDD. Also, running virt-sparsify again restores the smaller disk size. – orodbhen Dec 16 '16 at 14:42
  • +1 for the ServerFault reference. The OP offered the rsync --sparse command in their question – roaima Dec 16 '16 at 15:26
  • @roaima Thx. My question to orodbhen is about the local copy that they mention in an earlier comment. – xhienne Dec 16 '16 at 16:21
  • @orodbhen [same comment as earlier, I forgot to ping you] That's really strange. How do you copy your image locally? With cp or rsync? Can you try cp --sparse=always? – xhienne Dec 16 '16 at 16:24
  • @xhienne I used the exact same rsync command, minus the -z option. It's not over the network, so no compression needed. – orodbhen Dec 16 '16 at 17:05
0

The solution that I have found that works best for me is to first run

virt-sparsify imagename

Takes some time. That produces a smaller size image that reports the same size both in ls -h, du -h and du -h --apparent-size. But when you mount the image it reports the correct size (and grows as expected).

Then rsync that image.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.