qemu-block
[Top][All Lists]
Advanced

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

Re: [Qemu-block] [PATCH 0/2] qemu-img: Let "info" warn and go ahead with


From: Kevin Wolf
Subject: Re: [Qemu-block] [PATCH 0/2] qemu-img: Let "info" warn and go ahead without -U
Date: Tue, 9 Jan 2018 10:58:25 +0100
User-agent: Mutt/1.9.1 (2017-09-22)

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



reply via email to

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