From mboxrd@z Thu Jan  1 00:00:00 1970
Received: from eggs.gnu.org ([2001:4830:134:3::10]:55630)
	by lists.gnu.org with esmtp (Exim 4.71)
	(envelope-from <den@openvz.org>) id 1Z3Ljk-0002u8-A0
	for qemu-devel@nongnu.org; Fri, 12 Jun 2015 05:58:58 -0400
Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71)
	(envelope-from <den@openvz.org>) id 1Z3Ljg-0001FG-5R
	for qemu-devel@nongnu.org; Fri, 12 Jun 2015 05:58:56 -0400
Received: from relay.parallels.com ([195.214.232.42]:51348)
	by eggs.gnu.org with esmtp (Exim 4.71)
	(envelope-from <den@openvz.org>) id 1Z3Ljf-0001Em-Sn
	for qemu-devel@nongnu.org; Fri, 12 Jun 2015 05:58:52 -0400
Message-ID: <557AAD4B.10805@openvz.org>
Date: Fri, 12 Jun 2015 12:58:35 +0300
From: "Denis V. Lunev" <den@openvz.org>
MIME-Version: 1.0
References: <1433776886-27239-1-git-send-email-vsementsov@virtuozzo.com>
	<20150611200632.GA29013@stefanha-thinkpad.redhat.com>
In-Reply-To: <20150611200632.GA29013@stefanha-thinkpad.redhat.com>
Content-Type: text/plain; charset="windows-1252"; format=flowed
Content-Transfer-Encoding: 7bit
Subject: Re: [Qemu-devel] [PATCH v2 RFC 0/8] block: persistent dirty bitmaps
List-Id: <qemu-devel.nongnu.org>
List-Unsubscribe: <https://lists.nongnu.org/mailman/options/qemu-devel>,
	<mailto:qemu-devel-request@nongnu.org?subject=unsubscribe>
List-Archive: <http://lists.nongnu.org/archive/html/qemu-devel>
List-Post: <mailto:qemu-devel@nongnu.org>
List-Help: <mailto:qemu-devel-request@nongnu.org?subject=help>
List-Subscribe: <https://lists.nongnu.org/mailman/listinfo/qemu-devel>,
	<mailto:qemu-devel-request@nongnu.org?subject=subscribe>
To: Stefan Hajnoczi <stefanha@redhat.com>, Vladimir Sementsov-Ogievskiy <vsementsov@virtuozzo.com>
Cc: kwolf@redhat.com, jsnow@redhat.com, qemu-devel@nongnu.org, pbonzini@redhat.com

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.

partial read could be done in the next step