From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:51595) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1atYf6-0005fX-O2 for qemu-devel@nongnu.org; Fri, 22 Apr 2016 06:50:13 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1atYf2-0004zr-TF for qemu-devel@nongnu.org; Fri, 22 Apr 2016 06:50:12 -0400 Received: from plane.gmane.org ([80.91.229.3]:36517) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1atYf2-0004ze-N0 for qemu-devel@nongnu.org; Fri, 22 Apr 2016 06:50:08 -0400 Received: from list by plane.gmane.org with local (Exim 4.69) (envelope-from ) id 1atYex-0003pd-SC for qemu-devel@nongnu.org; Fri, 22 Apr 2016 12:50:03 +0200 Received: from barriere.frankfurter-softwarefabrik.de ([217.11.197.1]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Fri, 22 Apr 2016 12:50:03 +0200 Received: from lvml by barriere.frankfurter-softwarefabrik.de with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Fri, 22 Apr 2016 12:50:03 +0200 From: Lutz Vieweg Date: Fri, 22 Apr 2016 12:47:32 +0200 Message-ID: References: <20160420021101.GC8684@ad-mail.usersys.redhat.com> <20160420115036.GG6517@noname.str.redhat.com> Mime-Version: 1.0 Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit In-Reply-To: Subject: Re: [Qemu-devel] I/O errors reported to guest for raw-image-file backed /dev/vda - but host sees no I/O errors List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: qemu-devel@nongnu.org Cc: qemu-block@nongnu.org On 04/21/2016 05:54 PM, Lutz Vieweg wrote: > And indeed, the errors occured exactly at the time a backup procedure > was preparing a read-only snapshot with "btrfs subvolume snapshot -r" - > so until I can upgrade to a mainline kernel including the fix, I'll > pause the qemu process while the "btrfs subvolume snapshot -r" runs. Alas, this seems not to be sufficient to get rid of the symptom easily - I guess that some of the "pwrite"s are executed asynchronously, at a time when the qemu emulation is already in "pause" mode. Will retry with some safeguard sleep time between the "stop" to the monitor and the creation of the snapshot. Regards, Lutz Vieweg