From: Fam Zheng <famz@redhat.com>
To: Kevin Wolf <kwolf@redhat.com>
Cc: qemu-devel@nongnu.org, qemu-block@nongnu.org,
Max Reitz <mreitz@redhat.com>
Subject: Re: [Qemu-devel] [PATCH RFC] block: Tolerate existing writers on read only BdrvChild
Date: Fri, 3 Mar 2017 09:46:58 +0800 [thread overview]
Message-ID: <20170303014657.GA7097@lemon.lan> (raw)
In-Reply-To: <20170302142318.GA5868@noname.redhat.com>
On Thu, 03/02 15:23, Kevin Wolf wrote:
> Am 02.03.2017 um 12:21 hat Fam Zheng geschrieben:
> > On Wed, 03/01 17:22, Kevin Wolf wrote:
> > > Am 01.03.2017 um 17:10 hat Fam Zheng geschrieben:
> > > > On Wed, 03/01 16:16, Kevin Wolf wrote:
> > > > > > I'm not sure about this because: 1) this is intrusive from a user PoV, many
> > > > > > scripts and upper layer tools will stop working;
> > > > >
> > > > > Are you sure? I don't expect user scripts or even proper management
> > > > > tools to use qemu-io on running VMs. I do expect that some users are
> > > > > using 'convert -s' with running VMs despite our recommendation against
> > > > > it.
> > > > >
> > > > > If they are aware that they're doing something that works only in the
> > > > > right circumstances, then breaking it isn't nice. But my gut feeling is
> > > > > that most of them don't know about the implications of accessing a live
> > > > > image. In this case breaking their use case and making them think about
> > > > > whether they want to add something like a --force option sounds like a
> > > > > good thing because they aren't caught by surprise when things go wrong
> > > > > eventually.
> > > >
> > > > Yes, the use case is poor for qcow2, and your points stand there. But image
> > > > locking will be at the posix level, which has a wider range of users. I cannot
> > > > draw the same conclusion on raw images as easily.
> > >
> > > Well, with raw, I'm even less concerned about breaking the commands
> > > related to internal snapshots. :-)
> >
> > Yes, I'm agree with a --force there. For qemu-img map and qemu-io, personally I
> > think it's better to keep the default working. qemu-io is a expert mode tool,
> > whoever using it at all should already know what he's doing, --force doesn't add
> > much protection for the innocent.
>
> Being an expert doesn't protect you from stupid mistakes like forgetting
> that a VM is still running. --force doesn't prevent you from performing
> your evil action, but it prevents accidents where you didn't even intend
> to be evil for a change.
>
> I think qemu-io and qemu-img map are tools that only human users should
> be using while a VM is running, so breaking command line syntax
> compatibility by requiring a --force option wouldn't hurt too much.
OK, that sounds fair. I don't know how to implement the option, though, would
you like to take care of it? :)
Fam
prev parent reply other threads:[~2017-03-03 1:47 UTC|newest]
Thread overview: 9+ messages / expand[flat|nested] mbox.gz Atom feed top
2017-03-01 8:15 [Qemu-devel] [PATCH RFC] block: Tolerate existing writers on read only BdrvChild Fam Zheng
2017-03-01 9:49 ` Kevin Wolf
2017-03-01 12:39 ` Fam Zheng
2017-03-01 15:16 ` Kevin Wolf
2017-03-01 16:10 ` Fam Zheng
2017-03-01 16:22 ` Kevin Wolf
2017-03-02 11:21 ` Fam Zheng
2017-03-02 14:23 ` Kevin Wolf
2017-03-03 1:46 ` Fam Zheng [this message]
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=20170303014657.GA7097@lemon.lan \
--to=famz@redhat.com \
--cc=kwolf@redhat.com \
--cc=mreitz@redhat.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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.