Re: [Qemu-devel] [PATCH v2 16/16] iotests: Test qcow2's snapshot table handling

[Max Reitz <mreitz@redhat.com>]

[-- Attachment #1.1: Type: text/plain, Size: 1684 bytes --]

On 19.08.19 22:25, Eric Blake wrote:
> On 8/19/19 1:56 PM, Max Reitz wrote:
>> Add a test how our qcow2 driver handles extra data in snapshot table
>> entries, and how it repairs overly long snapshot tables.
>>
>> Signed-off-by: Max Reitz <mreitz@redhat.com>
>> ---
> 
>> +++ b/tests/qemu-iotests/261.out
>> @@ -0,0 +1,346 @@
>> +QA output created by 261
>> +
>> +=== Create v2 template ===
>> +
>> +Formatting 'TEST_DIR/t.IMGFMT.v2.orig', fmt=IMGFMT size=67108864
>> +No errors were found on the image.
>> +Snapshots in TEST_DIR/t.IMGFMT.v2.orig:
>> +  [0]
>> +    ID: 1
>> +    Name: sn0
>> +    Extra data size: 0
>> +  [1]
>> +    ID: 2
>> +    Name: sn1
>> +    Extra data size: 42
>> +    VM state size: 0
>> +    Disk size: 67108864
>> +    Unknown extra data: very important data
> 
> Hmm - possibly one more patch to write - but when checking snapshots for
> accuracy, do we want to insist that the 32-bit truncated VM state size
> is either 0 or matches the low 32-bits of the 64-bit VM state size
> field?  Any mismatch between those fields (other than the 32-bit field
> being left 0 because we knew to use the 64-bit field) might be a hint of
> a possible corruption.  But there's no good way to correct it other than
> wiping the 32-bit field to 0; and for a v2 image, any change we make to
> the 32-bit field might actually make the snapshot unusable for an older
> client that doesn't know how to use the 64-bit field.  So maybe we just
> overlook that.

The spec clearly says that when the 64-bit field is present, the 32-bit
field is to be ignored.  So there’s at least no standard-compliant way
of checking it.

Max


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