[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Qemu-devel] [PATCH 3/6] add-cow file format
From: |
Kevin Wolf |
Subject: |
Re: [Qemu-devel] [PATCH 3/6] add-cow file format |
Date: |
Wed, 01 Aug 2012 16:21:05 +0200 |
User-agent: |
Mozilla/5.0 (X11; Linux x86_64; rv:13.0) Gecko/20120605 Thunderbird/13.0 |
Am 01.08.2012 16:14, schrieb Stefan Hajnoczi:
> On Wed, Aug 1, 2012 at 2:57 PM, Eric Blake <address@hidden> wrote:
>> On 07/31/2012 10:51 AM, Dong Xu Wang wrote:
>>> This is the implementation code for add-cow file format. Because image_file
>>> might be very huge, then we can't read entire bitmap into memory, we must
>>> use
>>> a cache. Since qcow-cache.c has implemted cache code, we can create our
>>> cache
>>
>> s/implemted/implemented/
>>
>>> code based on it.
>>
>> Just wondering if Paolo's HBitmap code for drive-mirror might be a more
>> efficient way to implement your caching.
>>
>>>
>>> Signed-off-by: Dong Xu Wang <address@hidden>
>>> ---
>>> block/Makefile.objs | 1 +
>>> block/add-cow-cache.c | 206 +++++++++++++++++
>>> block/add-cow.c | 599
>>> +++++++++++++++++++++++++++++++++++++++++++++++++
>>> block/add-cow.h | 101 +++++++++
>>> block_int.h | 2 +
>>
>> Rather than adding a new implementation for code duplication, can you
>> refactor the existing implementation to be reusable, and update
>> qcow-cache.c to call into the common refactored code?
>
> I looked at this and block/qcow2-cache.c seems fairly clean and
> generic. The only things that need to be parameterized are the
> s->l2_table_cache/s->refcount_block_cache and s->cluster_size.
>
> These can be fixed by adding fields to Qcow2Cache:
> size_t table_size; /* cached table size in bytes */
> BlkDebugEvent flush_event;
> BlkDebugEvent load_event;
>
> Or maybe a table type enum (L2/refcount blocks/bitmap blocks).
>
> If Kevin agrees with extracting this from qcow2 (i.e. we can't add
> more qcow2-specific behavior easily in the future), then this looks
> doable.
I don't think we'd want to add qcow2 specific stuff there, and I've been
meaning to generalise it for quite a while, so feel free to do it.
One thing to note is that it currently depends on qcow2's s->lock being
taken while it's called. Eventually we'll want finer grained locking in
the cache itself and I believe this will also require some changes in
the interface, but for now add-cow can just do the same qcow2 and take
its global CoMutex.
Kevin