Re: [Qemu-devel] [PATCH v4 6/8] blockdev: add DriveBackup transaction

[Stefan Hajnoczi]

On Thu, May 16, 2013 at 01:21:19PM -0600, Eric Blake wrote:
> On 05/16/2013 02:36 AM, Stefan Hajnoczi wrote:
> > This patch adds a transactional version of the drive-backup QMP command.
> > It allows atomic snapshots of multiple drives along with automatic
> > cleanup if there is a failure to start one of the backup jobs.
> > 
> > Note that QMP events are emitted for block job completion/cancellation
> > and the block job will be listed by query-block-jobs.
> > 
> > @DriveBackup
> > 
> > @device: the name of the device whose writes should be mirrored.
> > 
> > @target: the target of the new image. If the file exists, or if it
> >          is a device, the existing file/device will be used as the new
> >          destination.  If it does not exist, a new file will be created.
> > 
> > @format: #optional the format of the new destination, default is to
> >          probe if @mode is 'existing', else the format of the source
> > 
> > @mode: #optional whether and how QEMU should create a new image, default is
> >        'absolute-paths'.
> > 
> > @speed: #optional the maximum speed, in bytes per second
> > 
> > Signed-off-by: Stefan Hajnoczi <address@hidden>
> > ---
> >  blockdev.c       | 53 +++++++++++++++++++++++++++++++++++++++++++++++++++++
> >  qapi-schema.json | 26 +++++++++++++++++++++++++-
> >  2 files changed, 78 insertions(+), 1 deletion(-)
> 
> Reviewed-by: Eric Blake <address@hidden>
> 
> Hmm, I wonder if we can simplify patch 3/8, by hoisting the DriveBackup
> definition into that patch, and writing:
> 
> { 'command': 'drive-backup',
>   'data': 'DriveBackup' }
> 
> instead of the current open-coding repetition of the arguments for the
> standalone command in comparison to the transaction action.  So far, all
> uses of { 'command':'str', 'data':{...} } in the qapi-schema.json use a
> direct object instead of a named type, but if we could fix the qapi code
> generation to honor dictionary types in place of an open-coded type, it
> might make our interface file more compact.

That would be nice.  The only thing to watch out for is a situation
where the transaction takes additional arguments that the regular
command does not.  But in most cases that would not be necessary.

> > +
> > +static void drive_backup_commit(BlkTransactionState *common)
> > +{
> > +    /* Block job has started, nothing to do here */
> > +}
> 
> Given this implementation, should we modify the extensible transaction
> series to allow for a NULL commit callback, and merely insist only that
> at least one of commit/abort is non-NULL (rather than the current
> insistence that commit is mandatory and abort is optional)?

If I need to respin I'll do that.