Am 17.11.2010 17:23, schrieb Stefan Hajnoczi:
> On Wed, Nov 17, 2010 at 1:41 PM, Kevin Wolf wrote:
>> Am 17.11.2010 13:43, schrieb Stefan Hajnoczi:
A typical sequence in qcow2 (simple cluster allocation) looks like this:
1. Update refcount table
2. bdrv_flush
3. Update L2
On Wed, Nov 17, 2010 at 1:41 PM, Kevin Wolf wrote:
> Am 17.11.2010 13:43, schrieb Stefan Hajnoczi:
>>> A typical sequence in qcow2 (simple cluster allocation) looks like this:
>>>
>>> 1. Update refcount table
>>> 2. bdrv_flush
>>> 3. Update L2 entry
>>>
>>> If we delay the operation and get three
On Wed, Nov 17, 2010 at 1:41 PM, Kevin Wolf wrote:
> Am 17.11.2010 13:43, schrieb Stefan Hajnoczi:
>>> A typical sequence in qcow2 (simple cluster allocation) looks like this:
>>>
>>> 1. Update refcount table
>>> 2. bdrv_flush
>>> 3. Update L2 entry
>>>
>>> If we delay the operation and get three
Am 17.11.2010 13:43, schrieb Stefan Hajnoczi:
> On Fri, Nov 5, 2010 at 6:38 PM, Kevin Wolf wrote:
>> Instead of directly executing writes and fsyncs, queue them and execute them
>> asynchronously. What makes this interesting is that we can delay syncs and if
>> multiple syncs occur, we can merge t
On Fri, Nov 5, 2010 at 6:38 PM, Kevin Wolf wrote:
> Instead of directly executing writes and fsyncs, queue them and execute them
> asynchronously. What makes this interesting is that we can delay syncs and if
> multiple syncs occur, we can merge them into one bdrv_flush.
The block-queue concept a
Instead of directly executing writes and fsyncs, queue them and execute them
asynchronously. What makes this interesting is that we can delay syncs and if
multiple syncs occur, we can merge them into one bdrv_flush.
A typical sequence in qcow2 (simple cluster allocation) looks like this:
1. Updat
