From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([208.118.235.92]:50945) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Svq2q-0002qM-Dn for qemu-devel@nongnu.org; Mon, 30 Jul 2012 09:30:09 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1Svq2e-0003Q5-ST for qemu-devel@nongnu.org; Mon, 30 Jul 2012 09:30:00 -0400 Received: from mx1.redhat.com ([209.132.183.28]:20970) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Svq2e-0003Pz-Ih for qemu-devel@nongnu.org; Mon, 30 Jul 2012 09:29:48 -0400 Message-ID: <50168C39.7000903@redhat.com> Date: Mon, 30 Jul 2012 15:29:29 +0200 From: Paolo Bonzini MIME-Version: 1.0 References: <1343127865-16608-1-git-send-email-pbonzini@redhat.com> <1343127865-16608-34-git-send-email-pbonzini@redhat.com> <5012B341.2080709@redhat.com> In-Reply-To: <5012B341.2080709@redhat.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Subject: Re: [Qemu-devel] [PATCH 33/47] mirror: add support for on-source-error/on-target-error List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Eric Blake Cc: kwolf@redhat.com, jcody@redhat.com, qemu-devel@nongnu.org, stefanha@linux.vnet.ibm.com Il 27/07/2012 17:26, Eric Blake ha scritto: > On 07/24/2012 05:04 AM, Paolo Bonzini wrote: >> Error management is important for mirroring; otherwise, an error on the >> target (even something as "innocent" as ENOSPC) requires to start again >> with a full copy. Similar to on_read_error/on_write_error, two separate >> knobs are provided for on_source_error (reads) and on_target_error (writes). >> The default is 'report' for both. >> >> The 'ignore' policy will leave the sector dirty, so that it will be >> retried later. Thus, it will not cause corruption. > > How frequently will the dirty sector be retried when the policy is > 'ignore'? Are we going to be causing a denial-of-service by repeatedly > retrying the sector until the user does something about the error event? A lot. It is definitely the "I know what I'm doing" kind of option. The usecase I had in mind was a network backend that had some kind of timeout-and-reconnect option, so that you know all failing operations will take at least a few seconds. Paolo >> +++ b/qapi-schema.json >> @@ -1389,17 +1389,27 @@ >> # (all the disk, only the sectors allocated in the topmost image, or >> # only new I/O). >> # >> +# @on-source-error: #optional the action to take on an error on the source, >> +# default 'report'. 'stop' and 'enospc' can only be used >> +# if the block device supports io-status (see BlockInfo). >> +# >> +# @on-target-error: #optional the action to take on an error on the target, >> +# default 'report' (no limitations, since this applies to >> +# a different block device than @device). >> +# >> # Returns: nothing on success >> # If @device is not a valid block device, DeviceNotFound >> # If @target can't be opened, OpenFileFailed >> # If @format is invalid, InvalidBlockFormat >> +# If @on_source_error is not supported, InvalidParameter > > s/_/-/g >