Re: [Qemu-devel] need to resurrect no-lock option?

[Fam Zheng <famz@redhat.com>]

On Thu, 09/21 13:43, Daniel P. Berrange wrote:
> On Thu, Sep 21, 2017 at 01:33:20PM +0100, Stefan Hajnoczi wrote:
> > On Wed, Sep 20, 2017 at 11:26:11AM +0200, Christian Ehrhardt wrote:
> > > Hi,
> > > this might have been discussed in the wake of the lock changes that took
> > > place in 2.10 but I can't find anything clear enough to follow in the
> > > current case.
> > > There was an old submission [1] by Fam to make it possible to no-lock
> > > qemu-img and others if needed. But it seems nothing like it made it along
> > > to the locking we have in 2.10.
> > > 
> > > One (maybe more) case where missing this causes pain is e.g. running an
> > > info check on a running guest.
> > > In general info shouldn't need a write lock anyway, but without --no-lock
> > > that use case is broken.
> > 
> > It's still an invalid use case.  There is no guarantee that qemu-img
> > will see a consistent version of the image file.  Metadata could change
> > underneath qemu-img because QEMU may still write to it.  QEMU may also
> > have some metadata cached so there's no guarantee that qemu-img sees an
> > up-to-date image.
> > 
> > Why do you need to run qemu-img on a disk image that is in use?
> 
> You have a directory full of images and you want to understand current usage
> vs potential future usage. For this you need to get the virtual size, which
> rquires 'qemu-img info' for non-raw files. Actually it would be even better
> served by the new 'measure' command recently added.
> 
> The job analyzing this directory of images may not have any context as to
> whether each file is in use by a running QEMU, so would just blindly call
> 'qemu-img info' on each file it finds.  There's of course potential that
> opening the image in 'qemu-img info' could hit problems if the running QEMU
> changed qcow2 metadata, but generally that would not have serious negative
> impact and would be self-correcting next time the job analysed the directory.

Probably it's helpful to add a hint about "--force-share" the in the error
message of "qemu-img info" when hitting an image lock failure?

Fam