qemu-block
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Qemu-block] Failed to get "consistent read" lock on a mirroring ima


From: Kevin Wolf
Subject: Re: [Qemu-block] Failed to get "consistent read" lock on a mirroring image
Date: Mon, 20 Nov 2017 14:41:29 +0100
User-agent: Mutt/1.9.1 (2017-09-22)

Am 20.11.2017 um 13:39 hat Eric Blake geschrieben:
> On 11/20/2017 04:37 AM, Kevin Wolf wrote:
> > [ Cc: qemu-block ]
> > 
> > Am 20.11.2017 um 09:47 hat Fam Zheng geschrieben:
> >> On Mon, 11/20 10:58, Han Han wrote:
> >>> Hello,
> >>> On qemu-2.10, I find 'qemu-img info' couldn't get the info of a mirroring
> >>> image:
> 
> >>
> >> Cc Kevin. Looks like -U here is not strong enough to skip the "consistent 
> >> read"
> >> lock. The drive mirror target BB shared permissions are different from 
> >> device
> >> BB, but I'm not sure if it is intentional.
> > 
> > I think there are two parts to this:
> > 
> > First, blocking consistent reads for the mirror target seems
> > unnecessary. I can send a patch to allow this in 2.11.
> 
> Doesn't the consistent read property mean that reading the image will
> see contents that a guest should have (had) access to at some point in
> time?  Until the mirroring reaches the READY state, the data is
> inconsistent (it is a mix of uninitialized data and partial guest data,
> while we continue to synchronize the rest of the guest data over the
> mirror), so it still makes sense to me that the consistent read blocker
> should be set at least until the mirror job switches into the second
> sync phase.

Yes, you're right. There may be some special cases where we actually get
a consistent view (if the target has the source as its backing file),
but generally speaking it's not consistent.

Okay, so let's leave this as it is for now.

> > The other part is that 'qemu-img info' doesn't actually need
> > BLK_PERM_CONSISTENT_READ, but blk_new_open() automatically requests it.
> > Maybe we need another flag that allows 'qemu-img info' to do without
> > this permission. The concrete use case are intermediate nodes of a
> > commit job, where we do have to block this permission.
> > 
> > Hm... Or is BDRV_O_NO_IO already the right flag for this? :-)
> 
> That's a good observation - as long as we aren't reading any
> guest-visible data from the image, we don't really care whether the
> guest-visible data is consistent.  BDRV_O_NO_IO is our promise that we
> are reading only metadata, not guest-visible data.  So that change makes
> sense.

I'll prepare a patch for this one then.

Kevin

Attachment: signature.asc
Description: PGP signature


reply via email to

[Prev in Thread] Current Thread [Next in Thread]