qcow2 becomes 37P in size while qemu crashes

[Chris Murphy <lists@colorremedies.com>]

Here is the bug write up so far, which contains most of the relevant details.
https://bugzilla.redhat.com/show_bug.cgi?id=1359325

Here are three teasers to get you to look at the bug:

1.
[root@f24m ~]# ls -lsh /var/lib/libvirt/images
total 57G
1.5G -rw-r-----. 1 qemu qemu 1.5G Jul 21 10:54
Fedora-Workstation-Live-x86_64-24-1.2.iso
1.4G -rw-r--r--. 1 qemu qemu 1.4G Jul 20 13:28
Fedora-Workstation-Live-x86_64-Rawhide-20160718.n.0.iso
4.4G -rw-r-----. 1 qemu qemu 4.4G Jul 22 10:43
openSUSE-Leap-42.2-DVD-x86_64-Build0109-Media.iso
 50G -rw-r--r--. 1 root root  37P Jul 22 13:23 uefi_opensuseleap42.2a3-1.qcow2
196K -rw-r--r--. 1 root root 193K Jul 22 08:46 uefi_opensuseleap42.2a3-2.qcow2
[root@f24m ~]#

Yes, it's using 50G worth of sectors on the drive. But then it's 37
Petabytes?! That's really weird.

[root@f24m ~]# df -h
Filesystem      Size  Used Avail Use% Mounted on
/dev/sda5       104G   67G   36G  65% /

2.
Btrfs mounts, reads, writes, just fine, no messages in dmesg other
than the usual mount messages; all before, during, and after the qemu
crash, and rebooting. I rebooted to do an offline btrfs check, which
has no complaints. Scrub has no complaints. Yes the qcow2 has +C xattr
set so there's no independent way to determine if/hoe it's corrupt.
But qemu-img does say it's corrupt and libvirt will not start the VM
anymore with this qcow2 attached.

3.
I've attached to the bug a filefrag -v output from the 37 P file,
which has ~900 extents. There's only one thing that's a bit out of the
ordinary, which is mentioned in the bug.

Pretty weird. To try to reproduce this I kinda need to delete that
qcow2 file. So if anyone has suggestions on what other information to
put in that bug report before I change the state of the system, lemme
know.

-- 
Chris Murphy