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 <mre...@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
signature.asc
Description: OpenPGP digital signature
