On Wed, 02/10 16:57, Denis V. Lunev wrote:
> On 02/10/2016 01:08 PM, Stefan Hajnoczi wrote:
> >On Sat, Jan 30, 2016 at 01:56:30PM +0300, Vladimir Sementsov-Ogievskiy wrote:
> >>Add qmp command to query dirty bitmap contents. This is needed for
> >>external backup.
> >>
> >>Signed-off-by: Vladimir Sementsov-Ogievskiy <vsement...@virtuozzo.com>
> >>---
> >>  block/dirty-bitmap.c         | 55 +++++++++++++++++++++++++++++++++++++++
> >>  blockdev.c                   | 62 
> >> ++++++++++++++++++++++++++++++++++++++++++++
> >>  include/block/dirty-bitmap.h |  7 +++++
> >>  qapi/block-core.json         | 54 ++++++++++++++++++++++++++++++++++++++
> >>  qmp-commands.hx              | 33 +++++++++++++++++++++++
> >>  5 files changed, 211 insertions(+)
> >This API produces large replies and/or requires many calls to fetch all
> >bitmap data.  The worst case is a 101010... bitmap.
> >
> >I consider the dirty bitmap to be data (vs control) and not something
> >that should be sent over a control channel like the QMP monitor.
> >
> >How about writing the dirty bitmap to a file?  The new bitmap file
> >format that Fam is working on could be used.  That way the dirty bitmap
> >can be saved asynchronously without hogging the QMP monitor.
> Reasonable point.
> 
> May be it would be better to setup "special" NBD server inside
> QEMU which will allow to directly "read" bitmap data.
> 
> Any opinion?

Since Stefan has mentioned "the format" I'm working on, yes, I think it will be
possible to expose the persistent bitmap through NBD if the driver assigns
node-names to the bitmap BDS.

Let me prototype this on top of my branch.

Fam

Reply via email to