On 01.02.2017 11:39, Alberto Garcia wrote:
> On Wed 01 Feb 2017 02:46:20 AM CET, Max Reitz wrote:
>
>>> The problem with the refcount table is that since it always occupies
>>> complete clusters its size is usually very big.
>>
>> Actually the main problem is that BDRVQcow2State.refcount_table_si
On Wed 01 Feb 2017 02:46:20 AM CET, Max Reitz wrote:
>> The problem with the refcount table is that since it always occupies
>> complete clusters its size is usually very big.
>
> Actually the main problem is that BDRVQcow2State.refcount_table_size
> is updated very generously as opposed to BDRVQ
On 30.01.2017 17:14, Alberto Garcia wrote:
> The metadata overlap checks introduced in a40f1c2add help detect
> corruption in the qcow2 image by verifying that data writes don't
> overlap with existing metadata sections.
>
> The 'refcount-block' check in particular iterates over the refcount
> tab
On 30.01.2017 17:34, Alberto Garcia wrote:
> On Mon 30 Jan 2017 05:14:41 PM CET, Alberto Garcia wrote:
>
>> This patch keeps the index of the last used (i.e. non-zero) entry in
>> the refcount table and updates it every time the table changes. The
>> refcount-block overlap check then uses that ind
On 01/30/2017 10:34 AM, Alberto Garcia wrote:
>
> I don't think QEMU produces files where refcount_table[i] == 0 but
> refcount_table[i + 1] != 0. Do they even make sense?
I don't know if qemu can be directly coerced to create such an image,
but a third party tool can (and that probably includes
On Mon 30 Jan 2017 05:14:41 PM CET, Alberto Garcia wrote:
> This patch keeps the index of the last used (i.e. non-zero) entry in
> the refcount table and updates it every time the table changes. The
> refcount-block overlap check then uses that index instead of reading
> the whole table.
Note tha
