On 18.01.19 16:25, Alberto Garcia wrote: > On Wed 16 Jan 2019 02:15:24 AM CET, james harvey wrote: > >> I ran: >> >> # qemu-img convert /var/lib/libvirt/images/win7.qcow2 -O raw >> /mnt/tmpqcow/win7.raw >> >> 45 minutes later, qemu-img had been running with 100% CPU every time I >> checked, and it had allocated the raw file, but still hadn't actually >> written a single byte: (note the dd in the VM completed the 90GB in >> about 8 minutes) > > [...] > >> After running this long, I ran strace for 15 seconds, here: >> https://termbin.com/gg9k -- It's repeatedly running lseek with >> SEEK_DATA and SEEK_HOLE. The SEEK_HOLE always results in 96251936768, >> and SEEK_DATA is different results. > > It seems like the problem addressed by this patch: > > https://lists.gnu.org/archive/html/qemu-block/2019-01/msg00246.html
But that patch is rather controversial. I don't think we've found a definitive solution for this issue yet (other than the fact that tmpfs is basically just buggy (is I think what we've claimed), and I think this is not the first time it was reported for btrfs either). I had some patches specifically for qemu-img convert, too, but the issue there was that conversion of preallocated qcow2 images on non-buggy filesystems got slower. So we somehow have to resolve that tradeoff... Max
signature.asc
Description: OpenPGP digital signature