[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Qemu-devel] [PATCH 0/3]: BLOCK_WATERMARK QMP event
From: |
Luiz Capitulino |
Subject: |
Re: [Qemu-devel] [PATCH 0/3]: BLOCK_WATERMARK QMP event |
Date: |
Wed, 10 Mar 2010 18:09:37 -0300 |
On Wed, 10 Mar 2010 09:40:42 +0100
Kevin Wolf <address@hidden> 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
- [Qemu-devel] [PATCH 3/3] QMP: Introduce BLOCK_WATERMARK event, (continued)
- Re: [Qemu-devel] [PATCH 0/3]: BLOCK_WATERMARK QMP event, Kevin Wolf, 2010/03/10
- Re: [Qemu-devel] [PATCH 0/3]: BLOCK_WATERMARK QMP event,
Luiz Capitulino <=
- Re: [Qemu-devel] [PATCH 0/3]: BLOCK_WATERMARK QMP event, Anthony Liguori, 2010/03/10
- Re: [Qemu-devel] [PATCH 0/3]: BLOCK_WATERMARK QMP event, Kevin Wolf, 2010/03/11
- Re: [Qemu-devel] [PATCH 0/3]: BLOCK_WATERMARK QMP event, Anthony Liguori, 2010/03/11
- Re: [Qemu-devel] [PATCH 0/3]: BLOCK_WATERMARK QMP event, Avi Kivity, 2010/03/11
- Re: [Qemu-devel] [PATCH 0/3]: BLOCK_WATERMARK QMP event, Anthony Liguori, 2010/03/11
- Re: [Qemu-devel] [PATCH 0/3]: BLOCK_WATERMARK QMP event, Avi Kivity, 2010/03/11
- Re: [Qemu-devel] [PATCH 0/3]: BLOCK_WATERMARK QMP event, Kevin Wolf, 2010/03/11
[Qemu-devel] Re: [PATCH 0/3]: BLOCK_WATERMARK QMP event, Kevin Wolf, 2010/03/10