qemu-devel.nongnu.org archive mirror
 help / color / mirror / Atom feed
From: Luiz Capitulino <lcapitulino@redhat.com>
To: Kevin Wolf <kwolf@redhat.com>
Cc: uril@redhat.com, qemu-devel@nongnu.org
Subject: Re: [Qemu-devel] [PATCH 0/3]: BLOCK_WATERMARK QMP event
Date: Wed, 10 Mar 2010 18:09:37 -0300	[thread overview]
Message-ID: <20100310180937.0e05b438@redhat.com> (raw)
In-Reply-To: <4B975B0A.1030502@redhat.com>

On Wed, 10 Mar 2010 09:40:42 +0100
Kevin Wolf <kwolf@redhat.com> wrote:

> Am 10.03.2010 00:08, schrieb Anthony Liguori:
> > On 03/09/2010 04:53 PM, Luiz Capitulino wrote:
> >>   Hi,
> >>
> >>   This series is based on a previous series submitted by Uri Lublin:
> >>
> >> http://lists.gnu.org/archive/html/qemu-devel/2009-03/msg00864.html
> >>
> >>   Details on the patches, except for this question: does it make sense to have
> >> a 'low' watermark for block devices?
> >>
> >>   I think it doesn't, then the event (and the monitor accompanying command)
> >> should be called BLOCK_HIGH_WATERMARK. But this makes the event very
> >> unflexible, so I have called it BLOCK_WATERMARK and added parameters for the
> >> high/low watermark type.
> >>    
> > 
> > The alternative way to implement this is for a management tool to just 
> > poll the allocated disk size periodically.
> 
> Then we need to provide that information using the monitor. As far as I
> know, we don't do that yet.

 No, we don't. We have a 'info blockstats' command though and it could
provide image related stats info if needed.

> Not doing that would mean that the
> management tool would have to open an image which is already in use by
> qemu (which is already something I feel uncomfortable about) and search
> for the highest allocated cluster (which makes it completely inefficient
> and therefore basically forbids the use case).
> 
> Really, we have no choice but to implement the high watermark tracking
> in the qemu block layer. The only question is if we have a monitor
> command to ask for the current value or if we signal an event if it goes
> above a given threshold.
> 
> I don't think I'm really decided on that question.

 I'm not either and that's why I'd like to hear from the management
tool people.

> > It's no more/less safe than generating an event on a "watermark" because 
> > the event is still racy with respect to a guest that's writing very 
> > quickly to the disk.
> 
> Being racy isn't a problem, a management tool doing this kind of things
> needs to use werror=ENOSPC (at least) anyway. The watermark thing, as I
> understand it, is only a mechanism to make it less likely that the VM
> has to be stopped.
> 
> Kevin

  reply	other threads:[~2010-03-10 21:09 UTC|newest]

Thread overview: 24+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2010-03-09 22:53 [Qemu-devel] [PATCH 0/3]: BLOCK_WATERMARK QMP event Luiz Capitulino
2010-03-09 22:53 ` [Qemu-devel] [PATCH 1/3] block-qcow2: keep highest allocated offset Luiz Capitulino
2010-03-09 22:53 ` [Qemu-devel] [PATCH 2/3] monitor: Introduce block_watermark command Luiz Capitulino
2010-03-09 22:53 ` [Qemu-devel] [PATCH 3/3] QMP: Introduce BLOCK_WATERMARK event Luiz Capitulino
2010-03-09 23:03 ` [Qemu-devel] [PATCH 0/3]: BLOCK_WATERMARK QMP event Anthony Liguori
2010-03-09 23:18   ` Luiz Capitulino
2010-03-09 23:08 ` Anthony Liguori
2010-03-09 23:22   ` Luiz Capitulino
2010-03-09 23:25     ` Luiz Capitulino
2010-03-09 23:55       ` Anthony Liguori
2010-03-10 21:02         ` Luiz Capitulino
2010-03-09 23:46     ` Anthony Liguori
2010-03-10  8:40   ` Kevin Wolf
2010-03-10 21:09     ` Luiz Capitulino [this message]
2010-03-10 21:20     ` Anthony Liguori
2010-03-11  8:34       ` Kevin Wolf
2010-03-11 14:19         ` Anthony Liguori
2010-03-11 14:58           ` Avi Kivity
2010-03-11 15:07             ` Anthony Liguori
2010-03-11 15:09               ` Avi Kivity
2010-03-11 16:16           ` Kevin Wolf
2010-03-10  8:33 ` [Qemu-devel] " Kevin Wolf
2010-03-10  9:28   ` Christoph Hellwig
2010-03-10 21:11     ` Luiz Capitulino

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=20100310180937.0e05b438@redhat.com \
    --to=lcapitulino@redhat.com \
    --cc=kwolf@redhat.com \
    --cc=qemu-devel@nongnu.org \
    --cc=uril@redhat.com \
    /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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).