qemu-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Qemu-devel] [PATCH 0/3]: BLOCK_WATERMARK QMP event


From: Kevin Wolf
Subject: Re: [Qemu-devel] [PATCH 0/3]: BLOCK_WATERMARK QMP event
Date: Wed, 10 Mar 2010 09:40:42 +0100
User-agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.1.7) Gecko/20100120 Fedora/3.0.1-1.fc12 Thunderbird/3.0.1

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. 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.

> 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 via email to

[Prev in Thread] Current Thread [Next in Thread]