From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:47189) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Z9xqK-0007Rc-O8 for qemu-devel@nongnu.org; Tue, 30 Jun 2015 11:53:10 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1Z9xqE-0005UE-6c for qemu-devel@nongnu.org; Tue, 30 Jun 2015 11:53:04 -0400 Received: from mx1.redhat.com ([209.132.183.28]:51565) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Z9xqD-0005Td-Un for qemu-devel@nongnu.org; Tue, 30 Jun 2015 11:52:58 -0400 Message-ID: <5592BB56.4020306@redhat.com> Date: Tue, 30 Jun 2015 11:52:54 -0400 From: John Snow MIME-Version: 1.0 References: <1435234332-581-1-git-send-email-stefanha@redhat.com> <1435234332-581-8-git-send-email-stefanha@redhat.com> <5591C90C.4020902@redhat.com> <20150630152755.GF31899@stefanha-thinkpad.redhat.com> In-Reply-To: <20150630152755.GF31899@stefanha-thinkpad.redhat.com> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Subject: Re: [Qemu-devel] [PATCH 07/10] block/backup: support block job transactions List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Stefan Hajnoczi Cc: Kevin Wolf , famz@redhat.com, Jeff Cody , qemu-devel@nongnu.org, mreitz@redhat.com, vsementsov@parallels.com On 06/30/2015 11:27 AM, Stefan Hajnoczi wrote: > On Mon, Jun 29, 2015 at 06:39:08PM -0400, John Snow wrote: >> >> >> On 06/25/2015 08:12 AM, Stefan Hajnoczi wrote: >>> Join the transaction when the backup block job is in incremental back= up >>> mode. >>> >>> This ensures that the sync bitmap is not thrown away if another block >>> job in the transaction is cancelled or fails. This is critical so >>> incremental backup with multiple disks can be retried in case of >>> cancellation/failure. >>> >>> Signed-off-by: Stefan Hajnoczi >>> --- >>> block/backup.c | 7 +++++- >>> blockdev.c | 73 ++++++++++++++++++++++++++++++++++++++++++------= ---------- >>> 2 files changed, 59 insertions(+), 21 deletions(-) >>> >>> diff --git a/block/backup.c b/block/backup.c >>> index ddf8424..fa86b0e 100644 >>> --- a/block/backup.c >>> +++ b/block/backup.c >>> @@ -429,6 +429,8 @@ static void coroutine_fn backup_run(void *opaque) >>> qemu_co_rwlock_wrlock(&job->flush_rwlock); >>> qemu_co_rwlock_unlock(&job->flush_rwlock); >>> =20 >>> + block_job_txn_prepare_to_complete(job->common.txn, &job->common,= ret); >>> + >>> if (job->sync_bitmap) { >>> BdrvDirtyBitmap *bm; >>> if (ret < 0 || block_job_is_cancelled(&job->common)) { >>> @@ -457,7 +459,7 @@ void backup_start(BlockDriverState *bs, BlockDriv= erState *target, >>> BlockdevOnError on_source_error, >>> BlockdevOnError on_target_error, >>> BlockCompletionFunc *cb, void *opaque, >>> - Error **errp) >>> + BlockJobTxn *txn, Error **errp) >>> { >>> int64_t len; >>> =20 >>> @@ -537,6 +539,9 @@ void backup_start(BlockDriverState *bs, BlockDriv= erState *target, >>> job->sync_mode =3D sync_mode; >>> job->sync_bitmap =3D sync_mode =3D=3D MIRROR_SYNC_MODE_DIRTY_BIT= MAP ? >>> sync_bitmap : NULL; >>> + if (job->sync_bitmap) { >>> + block_job_txn_add_job(txn, &job->common); >>> + } >> >> Hmm, is this what we want? This will add backup jobs to a transaction >> only if they have a bitmap attached to the job. >> >> However, if we're doing a mixture of full and incremental backups, we >> may still want to roll back the incremental backups if the full backup= s >> failed as part of the transaction. >> >> The (admittedly more complicated) design I submitted will always add a >> job to the transactional group, whether it has a bitmap or not. The >> membership test was only if it was launched by the backup transaction >> action. The bitmap is only checked for purposes of refcounting and >> cleanup mechanics. >> >> Maybe that wasn't what we wanted either, but this is a difference in h= ow >> our series will behave. >=20 > The 'backup' operation was added to the QMP 'transaction' command in > QEMU 1.6. If we add non-incremental backup commands to the transaction > then behavior changes. >=20 Ugh, good point... > Perhaps DriveBackup and BlockdevBackup QAPI structures should take an > optional 'transaction' bool argument. That way the caller decides whic= h > behavior to use. >=20 The way my version operated only changed the cleanup behavior -- it didn't attempt to cancel other jobs if they failed or not. It naively let them finish, then performed cleanup based on the overall completion status. That let the old behavior continue working like it did, but changed how incrementals worked upon completion. (1) Perhaps we can change the forced cancellation aspect and just allow jobs to finish naturally even in the event of failure. It's wasteful, but it does allow us to maintain the existing behavior while getting the behavior we want for incremental transactions. (2) Or, yes, add some sort of "all or nothing" flag to transactions(?*) that users can toggle on/off. I had wondered in the past if it wouldn't be advantageous for libvirt to be able to choose this behavior, if managing state of partial completions was desirable in some cases to avoid re-running operations unnecessarily. *As a thought, perhaps cancel-all-on-error as a flag can be a property of the QMP transaction command itself. When set, actions that launch jobs can add the job to the TXN. An error can be raised if the flag is used in conjunction with an action that doesn't currently/won't ever support the do-or-die flag.