From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:59508) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Zz4zq-0000qW-Cn for qemu-devel@nongnu.org; Wed, 18 Nov 2015 10:50:11 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1Zz4zp-0002Ln-Gn for qemu-devel@nongnu.org; Wed, 18 Nov 2015 10:50:10 -0500 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> <20151118150334.GF4817@noname.str.redhat.com> From: John Snow Message-ID: <564C9E26.7050208@redhat.com> Date: Wed, 18 Nov 2015 10:49:58 -0500 MIME-Version: 1.0 In-Reply-To: <20151118150334.GF4817@noname.str.redhat.com> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit 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: Kevin Wolf Cc: Vladimir Sementsov-Ogievskiy , Alberto Garcia , qemu-block@nongnu.org, qemu-devel@nongnu.org, Markus Armbruster , Stefan Hajnoczi , Paolo Bonzini , Fam Zheng , Max Reitz On 11/18/2015 10:03 AM, Kevin Wolf wrote: > Am 17.11.2015 um 18:05 hat John Snow geschrieben: >> Still the subject of debate on-list, but the thought is roughly 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 think the actual logical conclusion is that you use qcow2 images in > order to use the feature. > > Kevin > It's fine to say "To hell with raw," but for networked filesystems and other configurations that aren't using the qcow2 driver, I think it won't be a sufficient answer. qcow2 support is my first priority, but I think it can't be my only one.