From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([208.118.235.92]:55047) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1TOpsC-0005hD-HV for qemu-devel@nongnu.org; Thu, 18 Oct 2012 09:11:06 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1TOprv-0001bd-Qw for qemu-devel@nongnu.org; Thu, 18 Oct 2012 09:10:52 -0400 Received: from mx1.redhat.com ([209.132.183.28]:31943) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1TOprv-0001bD-DI for qemu-devel@nongnu.org; Thu, 18 Oct 2012 09:10:35 -0400 Received: from int-mx12.intmail.prod.int.phx2.redhat.com (int-mx12.intmail.prod.int.phx2.redhat.com [10.5.11.25]) by mx1.redhat.com (8.14.4/8.14.4) with ESMTP id q9IDAYAj016894 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK) for ; Thu, 18 Oct 2012 09:10:34 -0400 Message-ID: <507FFFC7.2090800@redhat.com> Date: Thu, 18 Oct 2012 15:10:31 +0200 From: Paolo Bonzini MIME-Version: 1.0 References: <1348675011-8794-1-git-send-email-pbonzini@redhat.com> <1348675011-8794-32-git-send-email-pbonzini@redhat.com> <507FFF21.2090007@redhat.com> In-Reply-To: <507FFF21.2090007@redhat.com> Content-Type: text/plain; charset=ISO-8859-15 Content-Transfer-Encoding: 7bit Subject: Re: [Qemu-devel] [PATCH v2 31/45] mirror: add support for on-source-error/on-target-error List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Kevin Wolf Cc: jcody@redhat.com, qemu-devel@nongnu.org Il 18/10/2012 15:07, Kevin Wolf ha scritto: >> > + s->synced = false; >> > + if (read) { >> > + return block_job_error_action(&s->common, s->common.bs, >> > + s->on_source_error, true, error); >> > + } else { >> > + return block_job_error_action(&s->common, s->target, >> > + s->on_target_error, false, error); > Here we produce an event that reports an error on s->bs, i.e. on the > source, even though the error was on the target. More precisely, this is an event that reports an error on s->bs's job. In principle there is no reason why asynchronous long-running operations are tied to a block device (in fact migration fits the definition quite well, with the only twist that the VM is stopped at the end), but that's the API we're stuck with. > This makes some sense > today that the target doesn't have a name, but once it has, we would > better use the target name here. > > Can we change this later on? If not, what's the way forward? Yes, we can change it to one of these: 1) produce both a BLOCK_JOB_ERROR event on the source and a BLOCK_IO_ERROR event on the target; 2) add a "device" argument to the BLOCK_JOB_ERROR and fill it. I think I prefer the latter, but it can be discussed separately. Paolo