block/backup: avoid copying less than full target clusters
commit4c9bca7e39a6e07ad02c1dcde3478363344ec60b
authorJohn Snow <jsnow@redhat.com>
Thu, 25 Feb 2016 20:58:30 +0000 (25 15:58 -0500)
committerJeff Cody <jcody@redhat.com>
Mon, 29 Feb 2016 19:55:14 +0000 (29 14:55 -0500)
treed301ab646b9a6936449cdc6b09201f245cb239bb
parent16096a4d4789ef1f260484b4cc18b8327cf0c928
block/backup: avoid copying less than full target clusters

During incremental backups, if the target has a cluster size that is
larger than the backup cluster size and we are backing up to a target
that cannot (for whichever reason) pull clusters up from a backing image,
we may inadvertantly create unusable incremental backup images.

For example:

If the bitmap tracks changes at a 64KB granularity and we transmit 64KB
of data at a time but the target uses a 128KB cluster size, it is
possible that only half of a target cluster will be recognized as dirty
by the backup block job. When the cluster is allocated on the target
image but only half populated with data, we lose the ability to
distinguish between zero padding and uninitialized data.

This does not happen if the target image has a backing file that points
to the last known good backup.

Even if we have a backing file, though, it's likely going to be faster
to just buffer the redundant data ourselves from the live image than
fetching it from the backing file, so let's just always round up to the
target granularity.

The same logic applies to backup modes top, none, and full. Copying
fractional clusters without the guarantee of COW is dangerous, but even
if we can rely on COW, it's likely better to just re-copy the data.

Reported-by: Fam Zheng <famz@redhat.com>
Signed-off-by: John Snow <jsnow@redhat.com>
Reviewed-by: Fam Zheng <famz@redhat.com>
Message-id: 1456433911-24718-3-git-send-email-jsnow@redhat.com
Signed-off-by: Jeff Cody <jcody@redhat.com>
block/backup.c