On Fri, Apr 17, 2020 at 5:34 PM John Snow wrote:
>
>
> On 4/17/20 6:57 PM, Leo Luan wrote:
> > On Fri, Apr 17, 2020 at 1:24 PM Eric Blake > <mailto:ebl...@redhat.com>> wrote:
> >
> > On 4/17/20 3:11 PM, John Snow wrote:
> >
On Fri, Apr 17, 2020 at 1:24 PM Eric Blake wrote:
> On 4/17/20 3:11 PM, John Snow wrote:
>
> >> +
> >> +if (s->sync_mode == MIRROR_SYNC_MODE_FULL &&
> >> + s->bcs->target->bs->drv != NULL &&
> >> + strncmp(s->bcs->target->bs->drv->format_name, "qcow2", 5) == 0
> &&
> >> +
On Fri, Apr 17, 2020 at 1:11 PM John Snow wrote:
>
>
> On 4/17/20 2:33 PM, Leo Luan wrote:
> > When doing a full backup from a single layer qcow2 disk file to a new
> > qcow2 file, the backup_run function does not unset unallocated parts in
> > the copy bit map. The
When doing a full backup from a single layer qcow2 disk file to a new qcow2
file, the backup_run function does not unset unallocated parts in the copy
bit map. The subsequent backup_loop call goes through these unallocated
clusters unnecessarily. In the case when the target and source reside in
Hi Eric and all,
When invoking "virsh backup-begin" to do a full backup using qcow2
driver to a new backup
target file that does not have a backing chain, is it safe to not zero
the unallocated
parts of the virtual disk? Do we still depend on SEEK_DATA support in
this case to avoid
forcing
