From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:54274) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ZysVM-0004WN-DX for qemu-devel@nongnu.org; Tue, 17 Nov 2015 21:29:53 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1ZysVL-000444-HD for qemu-devel@nongnu.org; Tue, 17 Nov 2015 21:29:52 -0500 Date: Wed, 18 Nov 2015 10:29:41 +0800 From: Fam Zheng Message-ID: <20151118022941.GA9000@ad.usersys.redhat.com> References: <1447108773-6836-1-git-send-email-mreitz@redhat.com> <1447108773-6836-4-git-send-email-mreitz@redhat.com> <20151112062349.GC4082@ad.usersys.redhat.com> <56466916.6040300@redhat.com> <20151116012745.GA21478@ad.usersys.redhat.com> <564A0D60.6080704@redhat.com> <20151117042251.GD28076@ad.usersys.redhat.com> <564B5E4B.4000406@redhat.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <564B5E4B.4000406@redhat.com> Subject: Re: [Qemu-devel] Closing Bitmaps (Was: Re: [PATCH v7 03/24] block: Release dirty bitmaps in bdrv_close()) List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: John Snow Cc: Kevin Wolf , Vladimir Sementsov-Ogievskiy , Alberto Garcia , qemu-block@nongnu.org, qemu-devel@nongnu.org, Markus Armbruster , Stefan Hajnoczi , Paolo Bonzini , Max Reitz 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. Fam