From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([208.118.235.92]:41293) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1UNL27-0003Y9-2Z for qemu-devel@nongnu.org; Wed, 03 Apr 2013 06:35:12 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1UNL20-0005YS-7F for qemu-devel@nongnu.org; Wed, 03 Apr 2013 06:35:10 -0400 Received: from e28smtp01.in.ibm.com ([122.248.162.1]:52918) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1UNL1z-0005NU-Ga for qemu-devel@nongnu.org; Wed, 03 Apr 2013 06:35:04 -0400 Received: from /spool/local by e28smtp01.in.ibm.com with IBM ESMTP SMTP Gateway: Authorized Use Only! Violators will be prosecuted for from ; Wed, 3 Apr 2013 16:00:47 +0530 Received: from d28relay01.in.ibm.com (d28relay01.in.ibm.com [9.184.220.58]) by d28dlp01.in.ibm.com (Postfix) with ESMTP id 6494FE004A for ; Wed, 3 Apr 2013 16:06:23 +0530 (IST) Received: from d28av05.in.ibm.com (d28av05.in.ibm.com [9.184.220.67]) by d28relay01.in.ibm.com (8.13.8/8.13.8/NCO v10.0) with ESMTP id r33AYaJv29753586 for ; Wed, 3 Apr 2013 16:04:36 +0530 Received: from d28av05.in.ibm.com (loopback [127.0.0.1]) by d28av05.in.ibm.com (8.14.4/8.13.1/NCO v10.0 AVout) with ESMTP id r33AYe5L002404 for ; Wed, 3 Apr 2013 21:34:40 +1100 Message-ID: <515C0584.4060503@linux.vnet.ibm.com> Date: Wed, 03 Apr 2013 18:33:40 +0800 From: Wenchao Xia MIME-Version: 1.0 References: <1364810491-21404-1-git-send-email-xiawenc@linux.vnet.ibm.com> <1364810491-21404-3-git-send-email-xiawenc@linux.vnet.ibm.com> <20130402135520.GJ2341@dhcp-200-207.str.redhat.com> <515BC36F.7080307@linux.vnet.ibm.com> <1466473402.1066275.1364973672613.JavaMail.root@redhat.com> <515BF023.8080701@linux.vnet.ibm.com> In-Reply-To: <515BF023.8080701@linux.vnet.ibm.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit Subject: Re: [Qemu-devel] [PATCH 2/3] block: adjust qmp_transaction to be extendable List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Paolo Bonzini Cc: Kevin Wolf , stefanha@gmail.com, qemu-devel@nongnu.org, dietmar@proxmox.com 于 2013-4-3 17:02, Wenchao Xia 写道: >> >> No, if bdrv_snapshot_delete() can fail, you need to split it in two >> parts: one that can fail, and one that cannot. If you cannot, then >> there are two possibilities: >> >> - if the failures are minor and could be repaired with "qemu-img check >> -r" >> (e.g. lost clusters), then this is not optimal but can still be done; >> >> - otherwise, the operation simply cannot be made transactionable. >> >> In the case of qcow2_snapshot_delete, everything except >> >> ret = bdrv_pwrite_sync(bs->file, offsetof(QCowHeader, nb_snapshots), >> &header_data, sizeof(header_data)); >> if (ret < 0) { >> goto fail; >> } >> >> must be in the prepare phase. Everything after "fail" (which right now >> is nothing, but it should at least undo the qcow2_alloc_clusters >> operation) >> must be in the rollback phase. Everything in the middle is the commit >> phase. >> >> Paolo >> > Sorry I haven't state it clearly. What about bdrv_snapshot_create() > operation? If it need to be rolled back, I think bdrv_snapshot_delete() > will get called and it may fail. But in most case if > bdrv_snapshot_create() succeed before, the bdrv_snapshot_delete should > succeed also, so if fail there may be unexpected error below, could > assert be used for this? > After consideration again, I think bdrv_snapshot_create() should be split apart like above, thank u for the tip. -- Best Regards Wenchao Xia