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

[Kevin Wolf <kwolf@redhat.com>]

Am 11.03.2010 15:19, schrieb Anthony Liguori:
> On 03/11/2010 02:34 AM, Kevin Wolf wrote:
>>
>> Well, if you're aware of the semantics of this value, it might be. It's
>> not exactly intuitive, but this is currently hidden inside qemu.
>>
>> What the high watermark says (in this implementation) is the highest
>> offset into the image file of an cluster that was allocated during this
>> qemu run. If you restart qemu, it starts at 0 again.
>>
>> I think there once was a version that tried to calculate the absolute
>> highest value when the image was opened, but it was reverted because it
>> just took too long. For the same reason I think a low watermark is
>> unrealistic, even if we get shrinking images some time. It's just not
>> doable efficiently, at least not in an easy way.
>>
>> I'm not sure if this semantics makes it a good public interface. Other
>> than that, I'm not overly concerned with doing it like you suggest.
> 
> Making it an event certainly exposes it as part of the public interface 
> though, no?

Not sure if we're talking about the same "it". If we generate an event
when the absolute value goes over a given threshold we hide the somewhat
non-intuitive part of the mechanism, which is the absolute number itself.

>> But honestly, while I do understand your point, this feels like a hack
>> to work around shortcomings of an interface. So what we need to decide
>> is which criterion outweighs the other in practice.
> 
> If I understand the use case correctly, what this really boils down to 
> is that you want to create a growable image on top of a non-growable 
> device.  The management tool then deals with growth using this interface.
> 
> I'm somewhat inclined to suggest that the proper way to support this is 
> to teach qemu how to grow the LVM volume like it would grow any normal file.

Hm... Never thought about that. I'm somewhat inclined to suggest that
you have a point there. :-)

This probably means that we finally need to get the image formats (raw,
qcow2, ...) and the protocols (file, host_cdrom, lvm, ...) properly
separated. Which is a good thing because we should do it anyway.

Kevin