[Top][All Lists]

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

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

From: Max Reitz
Subject: Re: [Qemu-devel] [RFC] Proposed qcow2 extension: subcluster allocation
Date: Tue, 11 Apr 2017 17:34:37 +0200
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.0

On 11.04.2017 17:30, Eric Blake wrote:
> On 04/11/2017 10:18 AM, Max Reitz wrote:
>> 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...
> Or we mix-and-match your ideas: since our subclusters are ternary
> encoding, if you want 128 subclusters, instead of asking for 256 bits,
> you ask for ld(3^128) = 203 bits, then use 11 padding bits of your
> original 64, and you have something that still fits in 256 bits instead
> of 512...
> Okay, just kidding.  Anything larger than 32 subclusters does get
> awkward fast.

If we want to do something a bit complicated that is still kind of
reasonable, though, we could just not use padding except for 512 byte
boundaries. Of course, that makes calculating the index of an L2 table a
bit more complicated (probably involving a division by a value that is
not a power of two), but it would kind of work.

Or we use Malbolge, yes. That would probably be the most sensible choice.


Attachment: signature.asc
Description: OpenPGP digital signature

reply via email to

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