All of lore.kernel.org
 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 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.