All of lore.kernel.org
 help / color / mirror / Atom feed
From: Fam Zheng <famz@redhat.com>
To: Kevin Wolf <kwolf@redhat.com>
Cc: qemu-devel@nongnu.org, Max Reitz <mreitz@redhat.com>,
	qemu-block@nongnu.org
Subject: Re: [Qemu-devel] [PATCH RFC] block: Tolerate existing writers on read only BdrvChild
Date: Thu, 2 Mar 2017 19:21:10 +0800	[thread overview]
Message-ID: <20170302112110.GA21732@lemon.lan> (raw)
In-Reply-To: <20170301162221.GD4799@noname.redhat.com>

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.

Fam

  reply	other threads:[~2017-03-02 11:21 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 [this message]
2017-03-02 14:23             ` Kevin Wolf
2017-03-03  1:46               ` Fam Zheng

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=20170302112110.GA21732@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.