On 06/14/2016 09:25 AM, Denis V. Lunev wrote: > Block commit of the active image to the backing store on a slow disk > could never end. For example with the guest with the following loop > inside > while true; do > dd bs=1k count=1 if=/dev/zero of=x > done > running above slow storage could not complete the operation with a
s/with/within/ > resonable amount of time: s/resonable/reasonable/ > virsh blockcommit rhel7 sda --active --shallow > virsh qemu-monitor-event > virsh qemu-monitor-command rhel7 \ > '{"execute":"block-job-complete",\ > "arguments":{"device":"drive-scsi0-0-0-0"} }' > virsh qemu-monitor-event > Completion event is never received. > > This problem could not be fixed easily with the current architecture. We > should either prohibit guest writes (making dirty bitmap dirty) or switch > to the sycnchronous scheme. s/sycnchronous/synchronous/ > > This patch implements the latter. It adds mirror_before_write_notify > callback. In this case all data written from the guest is synchnonously s/synchnonously/synchronously/ > written to the mirror target. Though the problem is solved partially. > We should switch from bdrv_dirty_bitmap to simple hbitmap. This will be > done in the next patch. > In other words, the mere act of mirroring a guest will now be guest-visible in that the guest is auto-throttled while waiting for the mirroring to be written out. It seems like you would want to be able to opt in or out of this scheme. Is it something that can be toggled mid-operation (try asynchronous, and switch to synchronous if a timeout elapses)? > Signed-off-by: Denis V. Lunev <d...@openvz.org> > Reviewed-by: Vladimir Sementsov-Ogievskiy<vsement...@virtuozzo.com> > CC: Stefan Hajnoczi <stefa...@redhat.com> > CC: Fam Zheng <f...@redhat.com> > CC: Kevin Wolf <kw...@redhat.com> > CC: Max Reitz <mre...@redhat.com> > CC: Jeff Cody <jc...@redhat.com> > CC: Eric Blake <ebl...@redhat.com> > --- > block/mirror.c | 78 > ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ > 1 file changed, 78 insertions(+) > I'll leave the actual idea to others to review, because there may be some ramifications that I'm not thinking of. -- Eric Blake eblake redhat com +1-919-301-3266 Libvirt virtualization library http://libvirt.org
signature.asc
Description: OpenPGP digital signature