On Fri, May 17, 2019 at 2:18 AM Lee Fleming <leeflemingster@xxxxxxxxx> wrote: > > I didn't see that particular warning. I did see a warning that it could cause damage and should be tried after trying some other things which I did. The data on this drive isn't important. I just wanted to see if it could be recovered before reinstalling. > > There was no crash, just a reboot. I was setting up KVM and I rebooted into a different kernel to see if some performance problems were kernel related. And it just didn't boot. OK the corrupted Btrfs volume is a guest file system? That's unexpected. There must be some configuration specific issue that's instigating this. I've done quite a lot of Btrfs testing in qemu-kvm including the virtioblk devices using unsafe caching, and I do vile things with the VM's intentionally trying to blow up Btrfs including force quitting the VM while it's writing. And I haven't gotten any corruptions. All I can recommend is to try to reproduce it again and this next time try to keep track of the exact steps such that anyone can try to reproduce it. It might be a bug you've found. But we need a reproducer. Is it using QCOW2 or RAW file backing, or LVM, or plain partition? What is the qemu command for the VM? You can get that with 'ps -aux | grep qemu' and it should show all the options used including the kind of block devices and caching. And then what is the workload inside the VM? -- Chris Murphy
