From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([208.118.235.92]:45119) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1SwXQr-0002Oq-8z for qemu-devel@nongnu.org; Wed, 01 Aug 2012 07:49:42 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1SwXQn-00037C-9z for qemu-devel@nongnu.org; Wed, 01 Aug 2012 07:49:41 -0400 Received: from mx1.redhat.com ([209.132.183.28]:36862) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1SwXQn-000375-1K for qemu-devel@nongnu.org; Wed, 01 Aug 2012 07:49:37 -0400 Message-ID: <501917CB.1060704@redhat.com> Date: Wed, 01 Aug 2012 13:49:31 +0200 From: Kevin Wolf 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> In-Reply-To: <50191044.7070109@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: Paolo Bonzini Cc: jcody@redhat.com, eblake@redhat.com, qemu-devel@nongnu.org, stefanha@linux.vnet.ibm.com Am 01.08.2012 13:17, schrieb Paolo Bonzini: > Il 01/08/2012 12:14, Kevin Wolf ha scritto: >>>> Signed-off-by: Paolo Bonzini >> If we want to switch to named target block devices later, it would >> probably make sense to use the io_status of that block device rather >> than adding it to the job. >> >> Maybe what results is a duplication that can be tolerated, though. > > We are probably thinking of two opposite implementations. > > You are thinking: > > - errors in streaming, or in the mirroring source go to the block device > > - errors in the mirroring target go to the block job > > What I implemented is: > > - errors in streaming, or in the mirroring source go to the block job > > - errors in the mirroring target go to the target block device (which as > of this series could be inspected with query-block-jobs). Ah, yes, I misunderstood. > The reason is that an error in streaming or in the mirroring source does > not stop the VM. A hypothetical management that polled for errors with > "info block" would see a mismatch between the error state ("failed") and > the VM RunState ("running"). > > So this is already ready for making the target block device visible. > > The real question is: if I remove the possibility to inspect the (so far > anonymous) target device with query-block-jobs, how do you read the > status of the target device?... You don't? :-) Maybe we should use named block devices from the beginning. Kevin