From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from [140.186.70.92] (port=53371 helo=eggs.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1PzC00-0000ln-Vu for qemu-devel@nongnu.org; Mon, 14 Mar 2011 13:56:10 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1PzBzz-000240-BX for qemu-devel@nongnu.org; Mon, 14 Mar 2011 13:56:08 -0400 Received: from mx1.redhat.com ([209.132.183.28]:55731) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1PzBzy-00023T-VG for qemu-devel@nongnu.org; Mon, 14 Mar 2011 13:56:07 -0400 Message-ID: <4D7E5727.5080205@redhat.com> Date: Mon, 14 Mar 2011 18:57:59 +0100 From: Kevin Wolf MIME-Version: 1.0 Subject: Re: [Qemu-devel] Re: Strategic decision: COW format References: <4D5BC467.4070804@redhat.com> <4D5E4271.80501@redhat.com> <20110220221357.GO4580@hall.aurel32.net> <4D62295E.1030504@redhat.com> <4D7D036B.4050706@codemonkey.ws> <4D7E167A.1020509@codemonkey.ws> <4D7E22FF.3090803@redhat.com> In-Reply-To: Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable List-Id: qemu-devel.nongnu.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Chunqiang Tang Cc: Stefan Hajnoczi , Aurelien Jarno , Markus Armbruster , qemu-devel@nongnu.org Am 14.03.2011 17:32, schrieb Chunqiang Tang: >>> FVD's novel uses of the reference count table reduces the metadata=20 > update >>> overhead down to literally zero during normal execution of a VM. This= =20 > gets >>> the bests of QCOW2's reference count table but without its oeverhead.= =20 > In >>> FVD, the reference count table is only updated when creating a new >>> snapshot or deleting an existing snapshot. The reference count table=20 > is >>> never updated during normal execution of a VM. >> >> Do you want to send out a break-down of the steps (and cost) involved = in=20 > doing: >> >> 1. Snapshot creation. >> 2. Snapshot deletion. >> 3. Opening an image with n snapshots. >=20 > Here is a detailed description. Relevant to the discussion of snapshot,= =20 > FVD uses a one-level lookup table and a refcount table. FVD=E2=80=99s o= ne-level=20 > lookup table is very similar to QCOW2=E2=80=99s two-level lookup table,= except=20 > that it is much smaller in FVD, and is preallocated and hence contiguou= s=20 > in image. Does this mean that FVD can't hold VM state of arbitrary size? > FVD=E2=80=99s refcount table is almost identical to that of QCOW2, but = with a key=20 > difference. An image consists of an arbitrary number of read-only=20 > snapshots, and a single writeable image front, which is the current ima= ge=20 > state perceived by the VM. Below, I will simply refer to the read-only=20 > snapshots as snapshots, and refer to the =E2=80=9Cwriteable image front= =E2=80=9D as=20 > =E2=80=9Cwriteable-front.=E2=80=9D QCOW2=E2=80=99s refcount table count= s clusters that are used by=20 > either read-only snapshots or writeable-front. Because writeable-front=20 > changes as the VM runs, QCOW2 needs to update the refcount table on the= =20 > fast path of normal VM execution.=20 Needs to update, but not necessarily on the fast path. Updates can be delayed and batched. Kevin