[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Qemu-stable] [PATCH v4 0/2] block: allow flush on devices with open
From: |
Kevin Wolf |
Subject: |
Re: [Qemu-stable] [PATCH v4 0/2] block: allow flush on devices with open tray |
Date: |
Tue, 20 Sep 2016 14:16:07 +0200 |
User-agent: |
Mutt/1.5.21 (2010-09-15) |
Am 19.09.2016 um 22:58 hat Max Reitz geschrieben:
> On 19.09.2016 18:44, John Snow wrote:
> > Final re-send for wording.
> >
> > The move to blk_flush altered the behavior of migration and flushing
> > nodes that are not reachable via the guest, but are still reachable
> > via QEMU and may or may not need to be flushed.
> >
> > This is likely the simplest solution for now until we nail down our
> > policy a bit more.
> >
> > This is intended for 2.6.2 and/or 2.7.1, to fix problems with libvirt
> > et al being unable to migrate QEMU when the CDROM tray is open.
> >
> > v4:
> > Commit message update.
> >
> > v3:
> > Trying to take a hint from Kevin, reinstating bdrv_flush_all.
> > If it's not what we want, we can try moving back to v2,
> > acknowledging that a nicer solution in the future:
> > (A) Can skip flushing on devices that just don't need it, and
> > (B) Optionally institutes some sort of flush-on-eject policy.
> >
> > ________________________________________________________________________________
> >
> > For convenience, this branch is available at:
> > https://github.com/jnsnow/qemu.git branch atapi-tray-migfix
> > https://github.com/jnsnow/qemu/tree/atapi-tray-migfix
> >
> > This version is tagged atapi-tray-migfix-v4:
> > https://github.com/jnsnow/qemu/releases/tag/atapi-tray-migfix-v4
> >
> > John Snow (2):
> > block: reintroduce bdrv_flush_all
> > qemu: use bdrv_flush_all for vm_stop et al
> >
> > block/io.c | 25 +++++++++++++++++++++++++
> > cpus.c | 4 ++--
> > include/block/block.h | 1 +
> > 3 files changed, 28 insertions(+), 2 deletions(-)
>
> Reviewed-by: Max Reitz <address@hidden>
Begs the question: Who is supposed to merge this? Stefan/Fam, who are
formally responsible for block/io.c? Or one of us because it's more
about managing block devices?
Kevin
pgpb3ocLVIKs7.pgp
Description: PGP signature