From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:37635) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Z3MKc-0002R4-JL for qemu-devel@nongnu.org; Fri, 12 Jun 2015 06:37:03 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1Z3MKZ-0001lw-AG for qemu-devel@nongnu.org; Fri, 12 Jun 2015 06:37:02 -0400 Received: from mx1.redhat.com ([209.132.183.28]:42293) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Z3MKZ-0001lk-5F for qemu-devel@nongnu.org; Fri, 12 Jun 2015 06:36:59 -0400 Date: Fri, 12 Jun 2015 11:36:56 +0100 From: Stefan Hajnoczi Message-ID: <20150612103656.GD623@stefanha-thinkpad.redhat.com> References: <1433776886-27239-1-git-send-email-vsementsov@virtuozzo.com> <20150611200632.GA29013@stefanha-thinkpad.redhat.com> <557AAD4B.10805@openvz.org> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="iVCmgExH7+hIHJ1A" Content-Disposition: inline In-Reply-To: <557AAD4B.10805@openvz.org> Subject: Re: [Qemu-devel] [PATCH v2 RFC 0/8] block: persistent dirty bitmaps List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: "Denis V. Lunev" Cc: kwolf@redhat.com, Vladimir Sementsov-Ogievskiy , jsnow@redhat.com, qemu-devel@nongnu.org, pbonzini@redhat.com --iVCmgExH7+hIHJ1A Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Fri, Jun 12, 2015 at 12:58:35PM +0300, Denis V. Lunev wrote: > On 11/06/15 23:06, Stefan Hajnoczi wrote: > >The load/store API is not scalable when bitmaps are 1 MB or larger. > > > >For example, a 500 GB disk image with 64 KB granularity requires a 1 MB > >bitmap. If a guest has several disk images of this size, then multiple > >megabytes must be read to start the guest and written out to shut down > >the guest. > > > >By comparison, the L1 table for the 500 GB disk image is less than 8 KB. > > > >I think something like qcow2-cache.c or metabitmaps should be used to > >lazily read/write persistent bitmaps. That way only small portions need > >to be read/written at a time. > > > >Stefan > for the first iteration we could open the image, start tracking, > read bitmap as one entity in the background and or read > and collected data. >=20 > partial read could be done in the next step Making bitmap load/store fully lazy will require changes to the load/store API, so it's worth thinking about a little upfront. Otherwise there will be a lot of code churn when the fully lazy patches are posted. As a reviewer it's in my interest to only spend time reviewing the final version instead of code that gets thrown out :-), but I understand. If you can make the read lazy to some extent that's a good start. --iVCmgExH7+hIHJ1A Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 iQEcBAEBAgAGBQJVerZIAAoJEJykq7OBq3PIFHUIALX+0dQRpOKTigOi8Q/VkR/m cBfWZCvWzUtz+hCbu+6XuQFFOYcUJ/oSmLmXPuty6x08BjpC5CpBTA3oOHATVovT Hw/uRo72sTd0Y2RD+hHuxT6OQlQdY7OBgP5Iti2gO34FgfxyIvW41WjSu5ferUW0 AINkbQPKrKCNlc8ngtF4QHNy2jvae+nJHYSNv0K6aWjXmCFt81Jl2BfwucArEvvo 2bPzF+r37xTtcoGC4b99SQOKMPgSsJ+FtS6biYWiYjZ/TshrVFyAlQPhQRa+ixrH vMwh/Yk3hp4SV6N6AyC/HUW9A+/cE+KcWMAxcDeSD1s0ApUM2TddoVT0G+JohHY= =BfVG -----END PGP SIGNATURE----- --iVCmgExH7+hIHJ1A--