From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:33024) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1astH6-0003dq-Bc for qemu-devel@nongnu.org; Wed, 20 Apr 2016 10:38:41 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1astGz-0000z9-Vm for qemu-devel@nongnu.org; Wed, 20 Apr 2016 10:38:40 -0400 Received: from plane.gmane.org ([80.91.229.3]:55261) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1astGz-0000ys-Og for qemu-devel@nongnu.org; Wed, 20 Apr 2016 10:38:33 -0400 Received: from list by plane.gmane.org with local (Exim 4.69) (envelope-from ) id 1astGw-0008OE-PH for qemu-devel@nongnu.org; Wed, 20 Apr 2016 16:38:30 +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 ; Wed, 20 Apr 2016 16:38:30 +0200 Received: from lvml by barriere.frankfurter-softwarefabrik.de with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Wed, 20 Apr 2016 16:38:30 +0200 From: Lutz Vieweg Date: Wed, 20 Apr 2016 16:38:19 +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: <20160420115036.GG6517@noname.str.redhat.com> 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/20/2016 01:50 PM, Kevin Wolf wrote: > To catch all possible write failures, I think pwrite, pwritev and > possibly fdatasync need to be considered. I've now a > strace -f -p 10727 -e trace=pwrite,pwritev,fdatasync,file -t 2>&1 | gzip -1 -c >trace.gz attached to the qemu-process. If the incident rate stays the same, by tomorrow I should be able to correlate newly emitted I/O-errors in the guest with that log. Regards, Lutz Vieweg