qemu-devel
[Top][All Lists]
Advanced

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

Re: [Qemu-devel] [RFC] qed: Add QEMU Enhanced Disk format


From: Kevin Wolf
Subject: Re: [Qemu-devel] [RFC] qed: Add QEMU Enhanced Disk format
Date: Fri, 10 Sep 2010 19:42:07 +0200
User-agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.1.12) Gecko/20100907 Fedora/3.0.7-1.fc12 Thunderbird/3.0.7

Am 10.09.2010 19:07, schrieb Anthony Liguori:
>>>> Sure, we'll support qcow2, but will we give it the same attention?
>>>
>>> We have a lot of block formats in QEMU today but only one block 
>>> format that actually performs well and has good data integrity.
>>>
>>> We're not giving qcow2 the attention it would need today to promote 
>>> it to a Useful Format so I'm not sure that it really matters.
>>
>> I don't think it's so useless.  It's really only slow when allocating, 
>> yes?  Once you've allocated it is fully async IIRC.
> 
> It bounces all buffers still and I still think it's synchronous 
> (although Kevin would know better).

Yes, it does bounce the buffers, though I'm looking into this anyway
because you raised concerns about unbounded allocations. (And it has
been on my todo list for a while, but there were always more urgent things)

What's synchronous in qcow2 is metadata access and COW. The guest
requests themselves are handled asynchronously. Once the image has
reached its full size, there are only metadata reads when you need to
load a different L2 table. With 64k clusters we have an L2 cache that
spans 8 GB of virtual disk space, so it shouldn't happen too often.

>>>>> If you're willing to leak blocks on a scale that is still unknown. 
>>>>
>>>> Who cares, those aren't real storage blocks.
>>>
>>> They are once you move the image from one place to another.  If that 
>>> doesn't concern you, it really should.
>>
>> I don't see it as a huge problem, certainly less than fsck. If you 
>> think fsck is a smaller hit, you can use it to recover the space.
>>
>> Hm, you could have an 'unclean shutdown' bit in qcow2 and run a 
>> scrubber in the background if you see it set and recover the space.
> 
> Yes, you'll want to have that regardless.  But adding new things to 
> qcow2 has all the problems of introducing a new image format.

Not exactly the same. The advantage of qed, namely not having the burden
of supporting all qcow2 features, is at the same time its biggest
disadvantage because it means that qcow2 can't be deprecated.

Adding things to qcow2 means staying compatible to older versions
(including all features) and still maintaining only one driver.

Kevin



reply via email to

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