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: Eric Blake
Subject: Re: [Qemu-block] Failed to get "consistent read" lock on a mirroring image
Date: Mon, 20 Nov 2017 06:39:02 -0600
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.4.0

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.

> 
> 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.

-- 
Eric Blake, Principal Software Engineer
Red Hat, Inc.           +1-919-301-3266
Virtualization:  qemu.org | libvirt.org

Attachment: signature.asc
Description: OpenPGP digital signature


reply via email to

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