[Top][All Lists]

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

Re: [Qemu-block] Closing Bitmaps (Was: Re: [Qemu-devel] [PATCH v7 03/24]

From: Fam Zheng
Subject: Re: [Qemu-block] Closing Bitmaps (Was: Re: [Qemu-devel] [PATCH v7 03/24] block: Release dirty bitmaps in bdrv_close())
Date: Wed, 18 Nov 2015 10:29:41 +0800
User-agent: Mutt/1.5.21 (2010-09-15)

On Tue, 11/17 12:05, John Snow wrote:
> Still the subject of debate on-list, but the thought is roughly this:

Thanks for summerizing this!

> Bitmaps will be able to flush-to-file on close. (If they have no
> persistence data, it's a no-op (maybe.)) This might mean being flushed
> to their own BDS -- the one they are describing -- as a qcow2 extension.
> Or, it could be to an arbitrary new standalone file format designed for
> the sole purpose of containing bitmap data.
> The discussion hasn't progressed beyond "Max and Kevin do not think
> storing arbitrary bitmaps in .qcow2 files is a good idea." The logical
> conclusion is "We need a new standalone format, then" but we haven't
> decided what that format will look like or how it will be used.

I second that. While storing dirty bitmap in the image itself sounds fine, it
is unlikely the best way for any other formats. Given that we will have a
standalone format for raw or other formats, it's probably not worth to extend
qcow2 specifically.

> Then, Through CLI arguments or QMP arguments, you can modify the
> persistence attributes of bitmaps -- choosing where to store them.
> Bitmaps for qcow2 nodes can be stored in their own node, bitmaps
> describing raw files will need to be stored in an external file.
> (Is it possible to create a block driver that doesn't implement
> read/write primitives, and only implements theoretical bitmap load/save
> primitives? We could create a block driver for a standalone bitmap
> container in this way...)

What about implementing it as a filter? It would work similar to blkdebug, with
.bdrv_co_writev to mark the in memory dirty bits (or even manage a
sophisticated cache to support large images efficiently), and .bdrv_close
to flush data to disk.

But that depends on the dynamic reconfigiration feature of block nodes, for
hot add/remove of dirty bitmap to work.


reply via email to

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