"Thomas L." <[email protected]> writes:
> Hi, > > I recently tried to use qemu-img with qcow2 images of my VMs and > qemu-img finds them corrupted. I can reproduce the issue in the > following way (on -current, but is the same on -stable; tried different > hosts to exclude hardware errors): > > marsden# vmctl create -s 300G test.qcow2 > vmctl: qcow2 imagefile created > marsden# qemu-img check test.qcow2 > No errors were found on the image. > Image end offset: 262144 > marsden# vmctl start -cL -B net -b /bsd.rd -d test.qcow2 test <snipped out the install log> > marsden# qemu-img check test.qcow2 > ERROR cluster 32769 refcount=0 reference=1 > > 1 errors were found on the image. > Data may be corrupted, or further writes to the image may corrupt it. > 39422/4915200 = 0.80% allocated, 3.31% fragmented, 0.00% compressed clusters > Image end offset: 2610888704 I've been able to reproduce the above, but interestingly if I "repair" the qcow2 image using: $ qemu-img -r all test.qcow2 It then reports 0 errors. Booting up the vm and installing packages like python3 and git and then cloning some git repos to work the disk, it still reports 0 errors. Interestingly, if I install something like an Alpine 3.13 guest (just an iso I had handy), qemu-img reports 0 errors. I also looked at a handful of qcow2 images on one of my workstations and seems only an Alpine and NixOS guest do not have this "corruption" report. However, I've never experienced any noticeable abnormalities. Since I see this from non-OpenBSD guests (Debian, for instance) it doesn't seem to be our vioblk(4) driver and is probably vmd(8)'s qcow2 implementation.. Anyone familiar enough with qcow2 that might make heads or tails of this? (cc'd ori@ as he was the original implementer.) -dv
