On Mon, Apr 18, 2022 at 12:21:39PM -0400, Dave Voutila wrote: > > "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 >
Yeah, Ori would be the right person to answer. If not I can take a look if I find the time.
