qemu-devel
[Top][All Lists]
Advanced

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

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


From: Daniel P. Berrange
Subject: Re: [Qemu-devel] need to resurrect no-lock option?
Date: Thu, 21 Sep 2017 13:43:17 +0100
User-agent: Mutt/1.8.3 (2017-05-23)

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.

Regards,
Daniel
-- 
|: https://berrange.com      -o-    https://www.flickr.com/photos/dberrange :|
|: https://libvirt.org         -o-            https://fstop138.berrange.com :|
|: https://entangle-photo.org    -o-    https://www.instagram.com/dberrange :|



reply via email to

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