qemu-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Qemu-devel] [PATCH 07/10] block/backup: support block job transacti


From: Stefan Hajnoczi
Subject: Re: [Qemu-devel] [PATCH 07/10] block/backup: support block job transactions
Date: Tue, 30 Jun 2015 16:27:55 +0100
User-agent: Mutt/1.5.23 (2014-03-12)

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 backup
> > 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 <address@hidden>
> > ---
> >  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);
> >  
> > +    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, 
> > BlockDriverState *target,
> >                    BlockdevOnError on_source_error,
> >                    BlockdevOnError on_target_error,
> >                    BlockCompletionFunc *cb, void *opaque,
> > -                  Error **errp)
> > +                  BlockJobTxn *txn, Error **errp)
> >  {
> >      int64_t len;
> >  
> > @@ -537,6 +539,9 @@ void backup_start(BlockDriverState *bs, 
> > BlockDriverState *target,
> >      job->sync_mode = sync_mode;
> >      job->sync_bitmap = sync_mode == MIRROR_SYNC_MODE_DIRTY_BITMAP ?
> >                         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 backups
> 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 how
> our series will behave.

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.

Perhaps DriveBackup and BlockdevBackup QAPI structures should take an
optional 'transaction' bool argument.  That way the caller decides which
behavior to use.

Attachment: pgp5fIM6mZftx.pgp
Description: PGP signature


reply via email to

[Prev in Thread] Current Thread [Next in Thread]