From: "Daniel P. Berrange" <berrange@redhat.com>
To: Stefan Hajnoczi <stefanha@gmail.com>
Cc: Christian Ehrhardt <christian.ehrhardt@canonical.com>,
Fam Zheng <famz@redhat.com>, qemu-devel <qemu-devel@nongnu.org>
Subject: Re: [Qemu-devel] need to resurrect no-lock option?
Date: Thu, 21 Sep 2017 13:43:17 +0100 [thread overview]
Message-ID: <20170921124317.GB15693@redhat.com> (raw)
In-Reply-To: <20170921123320.GG32364@stefanha-x1.localdomain>
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 :|
next prev parent reply other threads:[~2017-09-21 12:43 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
2017-09-20 9:26 [Qemu-devel] need to resurrect no-lock option? Christian Ehrhardt
2017-09-20 9:51 ` Fam Zheng
2017-09-20 10:04 ` Christian Ehrhardt
2017-09-21 12:33 ` Stefan Hajnoczi
2017-09-21 12:43 ` Daniel P. Berrange [this message]
2017-09-21 12:55 ` Fam Zheng
2017-09-21 13:18 ` Daniel P. Berrange
2017-09-22 7:27 ` Kevin Wolf
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20170921124317.GB15693@redhat.com \
--to=berrange@redhat.com \
--cc=christian.ehrhardt@canonical.com \
--cc=famz@redhat.com \
--cc=qemu-devel@nongnu.org \
--cc=stefanha@gmail.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).