[Top][All Lists]

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

Re: [Qemu-devel] [RFC] block-trace Low Level Command Supporting Disk Int

From: Paolo Bonzini
Subject: Re: [Qemu-devel] [RFC] block-trace Low Level Command Supporting Disk Introspection
Date: Wed, 15 May 2013 13:54:16 +0200
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130311 Thunderbird/17.0.4

Il 15/05/2013 11:46, Kevin Wolf ha scritto:
> Am 15.05.2013 um 11:16 hat Paolo Bonzini geschrieben:
>>>>> Does the "if there was no room" part mean that the mirror is active only
>>>>> sometimes?
>>>> Yes, otherwise the guest can allocate arbitrary amounts of memory in the
>>>> host just by starting a few very large I/O operations.
> On second thought, can't you do zero copy anyway for full cluster
> writes? This means that at most two clusters per request must be
> allocated, no matter how large it is, and you can probably reuse the
> same one-cluster buffer for both.

Only for synchronous mirror.  For an asynchronous mirror, there's no
guarantee that the mirror finishes writing before the source.  When that
fails, the guest can touch the memory and the mirror diverges from the

>>> I think I would rather throttle I/O in this case, i.e. requests wait
>>> until they can get the space. At least for a synchronous mirror we
>>> have to do something like this.
>> Yes, but this is still asynchronous.  The active part is just an optimization
>> to avoid write amplification (where small random writes require I/O of an 
>> entire
>> block as big as the bitmap granularity).
> Yes, that sounds like a good use case.
> But does this really cover all use cases a real synchronous active
> mirror would provide? I understood that Wolf wants to get every single
> guest request exposed e.g. on an NBD connection.

He can use throttling to limit the guest's I/O speed to the size of the
asynchronous mirror's buffer.


reply via email to

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