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
signature.asc
Description: OpenPGP digital signature