From: Paolo Bonzini <pbonzini@redhat.com>
To: Kevin Wolf <kwolf@redhat.com>
Cc: Wolfgang Richter <wolf@cs.cmu.edu>,
qemu-devel <qemu-devel@nongnu.org>,
stefanha <stefanha@redhat.com>
Subject: Re: [Qemu-devel] [RFC] block-trace Low Level Command Supporting Disk Introspection
Date: Wed, 15 May 2013 05:16:15 -0400 (EDT) [thread overview]
Message-ID: <1407889574.1806273.1368609375596.JavaMail.root@redhat.com> (raw)
In-Reply-To: <20130515085321.GB2858@dhcp-200-207.str.redhat.com>
> > We don't need a way to pass data from before to after hooks, a simple
> > scan of a linked list will do.
>
> So in this case the linked list is the way.
Point taken. :)
> > > Does the "if there was no room" part mean that the mirror is active only
> > > sometimes?
> >
> > Yes, otherwise the guest can allocate arbitrary amounts of memory in the
> > host just by starting a few very large I/O operations.
>
> I think I would rather throttle I/O in this case, i.e. requests wait
> until they can get the space. At least for a synchronous mirror we
> have to do something like this.
Yes, but this is still asynchronous. The active part is just an optimization
to avoid write amplification (where small random writes require I/O of an entire
block as big as the bitmap granularity).
> > > And why even bother with a dirty bitmap for an active mirror? The
> > > background job that sequentially processes the whole image only needs a
> > > counter, no bitmap.
> >
> > That's not enough for the case when the host crashes and you have to
> > restart the mirroring or complete it offline.
>
> You're thinking of a persistent bitmap here? Makes sense then, I didn't
> think about that.
Yes.
Paolo
next prev parent reply other threads:[~2013-05-15 9:16 UTC|newest]
Thread overview: 27+ messages / expand[flat|nested] mbox.gz Atom feed top
2013-05-13 21:21 [Qemu-devel] [RFC] block-trace Low Level Command Supporting Disk Introspection Wolfgang Richter
2013-05-14 8:40 ` Stefan Hajnoczi
2013-05-14 15:42 ` Wolfgang Richter
2013-05-14 8:50 ` Kevin Wolf
2013-05-14 10:04 ` Paolo Bonzini
2013-05-14 15:48 ` Wolfgang Richter
2013-05-14 16:45 ` Paolo Bonzini
2013-05-14 19:30 ` Wolfgang Richter
2013-05-15 7:59 ` Kevin Wolf
2013-05-15 8:25 ` Paolo Bonzini
2013-05-15 8:53 ` Kevin Wolf
2013-05-15 9:16 ` Paolo Bonzini [this message]
2013-05-15 9:46 ` Kevin Wolf
2013-05-15 11:54 ` Paolo Bonzini
2013-05-22 15:46 ` Wolfgang Richter
2013-05-14 15:45 ` Wolfgang Richter
2013-05-16 13:44 ` Richard W.M. Jones
2013-05-22 15:51 ` Wolfgang Richter
2013-05-22 16:11 ` Paolo Bonzini
2013-05-22 16:29 ` Wolfgang Richter
2013-05-22 16:42 ` Richard W.M. Jones
2013-05-22 18:32 ` Wolfgang Richter
2013-05-22 19:26 ` Richard W.M. Jones
2013-05-22 19:38 ` Wolfgang Richter
2013-05-22 20:47 ` Richard W.M. Jones
2013-05-22 21:46 ` Paolo Bonzini
2013-05-23 7:50 ` Stefan Hajnoczi
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=1407889574.1806273.1368609375596.JavaMail.root@redhat.com \
--to=pbonzini@redhat.com \
--cc=kwolf@redhat.com \
--cc=qemu-devel@nongnu.org \
--cc=stefanha@redhat.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.