All of lore.kernel.org
 help / color / mirror / Atom feed
From: Paolo Bonzini <pbonzini@redhat.com>
To: Wolfgang Richter <wolf@cs.cmu.edu>
Cc: Kevin Wolf <kwolf@redhat.com>,
	Stefan Hajnoczi <stefanha@gmail.com>, imain <imain@redhat.com>,
	Fam Zheng <famz@redhat.com>, qemu-devel <qemu-devel@nongnu.org>
Subject: Re: [Qemu-devel] drive-backup locks VM if target has issues?
Date: Mon, 30 Sep 2013 09:41:30 +0200	[thread overview]
Message-ID: <52492B2A.5070402@redhat.com> (raw)
In-Reply-To: <CACO=3k7fdU+kJ1Rr1H6dtSeLgar1b-WFzYeBj1FJeUrnxKX_Gw@mail.gmail.com>

Il 30/09/2013 00:46, Wolfgang Richter ha scritto:
> I wanted to explore overhead with the new drive-backup command and I
> noticed if I set the target to something like '/dev/null' the guest VM
> starts having IO errors and loses write access to its root file
> system.  Here is the qmp-shell command I'm using:
> 
>> drive-backup sync=none device=virtio0 target=/dev/null format=raw mode=existing
> 
> I have a guest running with a single virtio root disk (ext4, Ubuntu
> guest).  After that command, the guest sees write errors to its root
> block device (virtio0).

All writes to the drive-backup source have to first copy the pre-write
data to the target.  Thus, drive-backup usually works best if you are
using werror=stop on the source.  That said, I would have expected the
job to be cancelled instead.  Looks like there are bugs in the handling
of on_target_error.

> I didn't trace syscalls or dig deeper yet, but was wondering if you
> had an idea on why '/dev/null' as a target in a block job would cause
> the origin device to lockup/fail?
> 
> My overall goal is to drop the extra write traffic as early as
> possible to measure overhead of the drive-backup command in a few
> different scenarios, thus I was hoping /dev/null would help here.

I think you need a "null" backend instead that drops writes at the QEMU
level.  Perhaps /dev/zero helps too.

Paolo

  reply	other threads:[~2013-09-30  7:42 UTC|newest]

Thread overview: 3+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2013-09-29 22:46 [Qemu-devel] drive-backup locks VM if target has issues? Wolfgang Richter
2013-09-30  7:41 ` Paolo Bonzini [this message]
2013-09-30 14:47   ` Wolfgang Richter

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=52492B2A.5070402@redhat.com \
    --to=pbonzini@redhat.com \
    --cc=famz@redhat.com \
    --cc=imain@redhat.com \
    --cc=kwolf@redhat.com \
    --cc=qemu-devel@nongnu.org \
    --cc=stefanha@gmail.com \
    --cc=wolf@cs.cmu.edu \
    /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.