Ori Bernstein <o...@eigenstate.org> writes:
> Yep. I can look at it in a few days. > > I'm assuming that the vm was stopped before running the check? > Yes. > On April 18, 2022 3:42:50 PM EDT, Mike Larkin <mlar...@nested.page> wrote: > > On Mon, Apr 18, 2022 at 12:21:39PM -0400, Dave Voutila wrote: > > "Thomas L." <tom.longsh...@web.de> 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. -- -Dave Voutila