From mboxrd@z Thu Jan 1 00:00:00 1970 From: Paolo Bonzini Subject: Re: Kernel 4.4.0 KVM guest on Btrfs locks up on snapshotting Date: Tue, 19 Jan 2016 23:18:59 +0100 Message-ID: <569EB653.9080700@redhat.com> References: <20160120030223.22cc3ae0@natsu> Mime-Version: 1.0 Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit To: Roman Mamedov , linux-btrfs@vger.kernel.org, kvm@vger.kernel.org Return-path: In-Reply-To: <20160120030223.22cc3ae0@natsu> Sender: linux-btrfs-owner@vger.kernel.org List-Id: kvm.vger.kernel.org On 19/01/2016 23:02, Roman Mamedov wrote: > Hello, > > I'm facing a strange issue: > > Starting with the kernel 4.4.0, a KVM guest stored on a Btrfs > filesystem, if it's using the "virtio-scsi" disk backend, will hard > lock-up instantly, as soon as the Btrfs subvolume which contains > its backing file is snapshotted. So this is kernel 4.4 on the host, and virtio-scsi in the guest. What about virtio-blk in the guest? The only difference I can see between ide and virtio-* is that IDE only has a queue depth of 1. > There's nothing in dmesg neither on the guest, nor on the host; the > KVM process can be killed from the host just fine and then > restarted, so it doesn't seem to be a kernel-side deadlock of any > sort. > > KVM disk controller which exhibits the problem: > > -device virtio-scsi-pci,id=scsi -device scsi-hd,drive=hd \ > > The alternative which works fine: > > -device ide-hd,drive=hd,bus=ide.0 \ > > The disk device line is common to both cases: > > -drive > if=none,id=hd,cache=writeback,aio=threads,format=raw,file=$NAME.img,discard=unmap,detect-zeroes=unmap > \ So you're snapshotting the subvolume that includes $NAME.img? Paolo