From: Kevin Wolf <kwolf@redhat.com>
To: Fam Zheng <famz@redhat.com>
Cc: Nir Soffer <nirsof@gmail.com>,
qemu-devel@nongnu.org, qemu-block@nongnu.org,
Max Reitz <mreitz@redhat.com>, Ala Hino <ahino@redhat.com>
Subject: Re: [Qemu-devel] [Qemu-block] [PATCH 0/2] qemu-img: Let "info" warn and go ahead without -U
Date: Tue, 9 Jan 2018 10:58:25 +0100 [thread overview]
Message-ID: <20180109095825.GB6063@localhost.localdomain> (raw)
In-Reply-To: <20180109062425.GA18346@lemon.usersys.redhat.com>
Am 09.01.2018 um 07:24 hat Fam Zheng geschrieben:
> On Mon, 01/08 18:57, Kevin Wolf wrote:
> > I'm not sure if going back to the old behaviour for a while now would be
> > helpful, you'd just end up with an even more confusing set of qemu
> > versions, for example:
> >
> > <= 2.9 - works without a warning
> > 2.10 and 2.11 - errors out
> > 2.12 - prints a warning, but works
> > >= 2.13 - errors out again
>
> What I had in mind is settle on warning for good. QEMU (including qemu-img) is a
> low level tool that can be used in many ways that it isn't supposed to, this one
> is not more harmful than others (e.g. "qemu-img snapshot ..." on iscsi:// qcow2
> image) we allow siliently.
>
> I know this is debatable but I think the #1 purpose of image locking is to
> prevent data corruption;
Isn't potentially wrong output of 'qemu-img info' a form of data
corruption? Not data as in disk content, but metadata is data, too.
> #2 IMO is to reduce confusion and misinformation.
> While inconsistent output of "qemu-img info" is misinformation, it not working
> as before is actually confusion. Though the current behavior is indeed ideal,
> the proposed patch is a bit more pragmatical.
To be clear: If we want to minimise confusing by change, we have to
disable locking by default, not only here but everywhere else. And
therefore make it completely useless.
The whole point of locking is to change something in order to make
things safer. Yes, this may inconvenience users who want to do something
unsafe. Tough luck. The only other option is not making things safer.
We already successfully made a point that tools (libvirt with shared
images, or libguestfs) need to update their qemu invocation for qemu
proper. They didn't like it, but they could see the point, and it has
been this way for two releases already. So I don't see a compelling
reason why now we should give up again some of the safety we achieved
long-term.
If we were designing qemu-img from scratch, it would be an error. So
that's what it should be in the long term. Tools should preferably use
'query-block' and friends rather 'qemu-img info' if the image is in use.
Kevin
next prev parent reply other threads:[~2018-01-09 9:58 UTC|newest]
Thread overview: 20+ messages / expand[flat|nested] mbox.gz Atom feed top
2018-01-05 6:55 [Qemu-devel] [PATCH 0/2] qemu-img: Let "info" warn and go ahead without -U Fam Zheng
2018-01-05 6:55 ` [Qemu-devel] [PATCH 1/2] qemu-img: Move img_open error reporting to callers Fam Zheng
2018-01-05 16:03 ` Eric Blake
2018-01-05 6:55 ` [Qemu-devel] [PATCH 2/2] qemu-img: info: try -U automatically Fam Zheng
2018-01-05 16:08 ` Eric Blake
2018-01-08 14:41 ` [Qemu-devel] [PATCH 0/2] qemu-img: Let "info" warn and go ahead without -U Kevin Wolf
2018-01-08 17:07 ` [Qemu-devel] [Qemu-block] " Nir Soffer
2018-01-08 17:57 ` Kevin Wolf
2018-01-09 6:24 ` Fam Zheng
2018-01-09 9:58 ` Kevin Wolf [this message]
2018-01-09 19:58 ` Ala Hino
2018-01-09 20:11 ` Eric Blake
2018-01-09 20:29 ` Ala Hino
2018-01-10 12:51 ` Daniel P. Berrange
2018-01-10 12:49 ` [Qemu-devel] " Daniel P. Berrange
2018-01-10 14:07 ` Kevin Wolf
2018-01-10 14:13 ` Daniel P. Berrange
2018-01-10 14:03 ` Kashyap Chamarthy
2018-01-10 16:43 ` [Qemu-devel] [Qemu-block] " Nir Soffer
2018-01-11 9:26 ` Kashyap Chamarthy
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=20180109095825.GB6063@localhost.localdomain \
--to=kwolf@redhat.com \
--cc=ahino@redhat.com \
--cc=famz@redhat.com \
--cc=mreitz@redhat.com \
--cc=nirsof@gmail.com \
--cc=qemu-block@nongnu.org \
--cc=qemu-devel@nongnu.org \
/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).