[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: |
Kevin Wolf |
Subject: |
Re: [Qemu-devel] [PATCH 0/3]: BLOCK_WATERMARK QMP event |
Date: |
Thu, 11 Mar 2010 17:16:32 +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 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
- Re: [Qemu-devel] [PATCH 0/3]: BLOCK_WATERMARK QMP 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, 2010/03/10
- 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 <=
[Qemu-devel] Re: [PATCH 0/3]: BLOCK_WATERMARK QMP event, Kevin Wolf, 2010/03/10