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