Re: [Qemu-devel] [RFC] Proposed qcow2 extension: subcluster allocation

[Max Reitz <mreitz@redhat.com>]

[-- Attachment #1: Type: text/plain, Size: 2363 bytes --]

On 11.04.2017 17:29, Kevin Wolf wrote:
> Am 11.04.2017 um 17:18 hat Max Reitz geschrieben:
>> On 11.04.2017 17:08, Eric Blake wrote:
>>> On 04/11/2017 09:59 AM, Max Reitz wrote:
>>>
>>>>
>>>> Good point, but that also means that (with (2)) you can only use
>>>> subcluster configurations where the L2 entry size increases by a power
>>>> of two. Unfortunately, only one of those configurations itself is a
>>>> power of two, and that is 32.
>>>>
>>>> (With 32 subclusters, you take up 64 bits, which means an L2 entry will
>>>> take 128 bits; with any higher 2^n, you'd take up 2^{n+1} bits and the
>>>> L2 entry would take 2^{n+1} + 64 which is impossible to be a power of two.)
>>>
>>> Or we add padding. If you want 64 subclusters, you burn 256 bits per> entry, even though only 192 of those bits are used.
>>
>> Hm, yeah, although you have to keep in mind that the padding is almost
>> pretty much the same as the the data bits we need, effectively doubling
>> the size of the L2 tables:
>>
>> padding = 2^{n+2} - 2^{n+1} - 64 (=2^6)
>>         = 2^{n+1} - 64
>>
>> So that's not so nice, but if it's the only thing we can do...
>>
>>>> I don't know how useful non-power-of-two subcluster configurations are.
>>>> Probably not at all.
>>>>
>>>> Since using subcluster would always result in the L2 table taking more
>>>> than 512 bytes, you could therefore never guarantee that there is no
>>>> entry overlapping a sector border (except with 32 subclusters).
>>>
>>> Yes, there's definite benefits to keeping whatever structure we end up
>>> with aligned so that it naturally falls into sector boundaries, even if
>>> it means more padding bits.
>>
>> Then again, I'm not even sure we really need atomicity for L2 entries +
>> subcluster bits. I don't think you'd ever have to modify both at the
>> same time (if you just say the subclusters are all unallocated when
>> allocating the cluster itself, and then you write which subclusters are
>> actually allocated afterwards)).
>>
>> (This also applies to your remark on caching, I think.)
>>
>> Atomicity certainly makes things easier, though.
> 
> Unless you want to deal with ordering (i.e. on cluster allocation, first
> update the subcluster bitmap, then flush, then add the L2 entry), I
> think you need atomicity.

Yes, that's what I meant.

Max


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 512 bytes --]