From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([208.118.235.92]:43188) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1SyL0l-0000iP-J2 for qemu-devel@nongnu.org; Mon, 06 Aug 2012 06:58:12 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1SyL0k-0001VC-Jc for qemu-devel@nongnu.org; Mon, 06 Aug 2012 06:58:11 -0400 Received: from mail-pb0-f45.google.com ([209.85.160.45]:56038) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1SyL0k-0001V1-Cv for qemu-devel@nongnu.org; Mon, 06 Aug 2012 06:58:10 -0400 Received: by pbbro12 with SMTP id ro12so5118809pbb.4 for ; Mon, 06 Aug 2012 03:58:09 -0700 (PDT) Sender: Paolo Bonzini Message-ID: <501FA33A.2080004@redhat.com> Date: Mon, 06 Aug 2012 12:58:02 +0200 From: Paolo Bonzini MIME-Version: 1.0 References: <1343127865-16608-1-git-send-email-pbonzini@redhat.com> <1343127865-16608-14-git-send-email-pbonzini@redhat.com> <5019016F.1050909@redhat.com> <50191044.7070109@redhat.com> <501917CB.1060704@redhat.com> <50191C97.8000005@redhat.com> <50191FA7.1070309@redhat.com> <50192182.8070509@redhat.com> <50192A8D.3000309@redhat.com> <50192D49.6030504@redhat.com> <501936C9.40006@redhat.com> <50193E84.7050503@redhat.com> <5019445F.9010308@redhat.com> <501947FD.2080201@redhat.com> <501F8E8F.5000509@redhat.com> <501F91F9.6040602@redhat.com> <501FA04D.5070002@redhat.com> In-Reply-To: <501FA04D.5070002@redhat.com> Content-Type: text/plain; charset=ISO-8859-15 Content-Transfer-Encoding: 7bit Subject: Re: [Qemu-devel] [PATCH 13/47] block: introduce block job error List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Kevin Wolf Cc: jcody@redhat.com, eblake@redhat.com, qemu-devel@nongnu.org, stefanha@linux.vnet.ibm.com Il 06/08/2012 12:45, Kevin Wolf ha scritto: >> In the long term >> we will add the failing blockdev name to the blockjob iostatus. > I think you misunderstood. What I was trying to say is that with the > same reasoning we'd need a field that doesn't automatically reset its > status on 'cont' not only for block jobs, but also for regular guest disks. I'm not sure why. There cannot be changes to the guest-triggered iostatus after you do a stop. On the other hand, a block job still runs while the guest is stopped (and we cannot change this because it'd be backwards-incompatible), so you can have the following (> means command, < means event): > stop (no iostatus) < BLOCK_JOB_ERROR (iostatus=failed on source) > cont (no iostatus) libvirtd restarts > query-block (no iostatus) Compare this with guest-initiated I/O: > stop (no iostatus) < BLOCK_IO_ERROR (iostatus=failed) > cont (no iostatus) libvirtd restarts QEMU retries I/O, fails < BLOCK_IO_ERROR (iostatus=failed) > query-block (iostatus=failed) > If you try fixing the problem by adding a field in BlockJob, it may well > be fixed for block jobs, but you still need to add it in the generic > place later so that regular disks are covered as well. Regular disks are covered because each entry in query-block has its own iostatus. The only problematic case is now if two different backing files fail for unrelated reasons. Paolo