From mboxrd@z Thu Jan  1 00:00:00 1970
Received: from eggs.gnu.org ([2001:4830:134:3::10]:48401)
	by lists.gnu.org with esmtp (Exim 4.71)
	(envelope-from <k.razavi@vu.nl>) id 1V9bGg-0001gD-Cs
	for qemu-devel@nongnu.org; Wed, 14 Aug 2013 09:37:50 -0400
Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71)
	(envelope-from <k.razavi@vu.nl>) id 1V9bGX-0003wd-La
	for qemu-devel@nongnu.org; Wed, 14 Aug 2013 09:37:42 -0400
Received: from mailin.vu.nl ([130.37.164.16]:55539)
	by eggs.gnu.org with esmtp (Exim 4.71)
	(envelope-from <k.razavi@vu.nl>) id 1V9bGX-0003wH-Fp
	for qemu-devel@nongnu.org; Wed, 14 Aug 2013 09:37:33 -0400
Message-ID: <520B881A.8080101@cs.vu.nl>
Date: Wed, 14 Aug 2013 15:37:30 +0200
From: Kaveh Razavi <kaveh@cs.vu.nl>
MIME-Version: 1.0
References: <1376413436-5424-1-git-send-email-kaveh@cs.vu.nl>
	<8737CB0DA803476059F56AF5@nimrod.local> <520B69D5.3070505@cs.vu.nl>
	<962306F5-8851-498D-A629-C0BC59AD3758@alex.org.uk>
In-Reply-To: <962306F5-8851-498D-A629-C0BC59AD3758@alex.org.uk>
Content-Type: text/plain; charset="ISO-8859-1"
Content-Transfer-Encoding: 7bit
Subject: Re: [Qemu-devel] [PATCH] Introduce cache images for the QCOW2 format
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: Alex Bligh <alex@alex.org.uk>
Cc: Kevin Wolf <kwolf@redhat.com>, qemu-devel@nongnu.org, Stefan Hajnoczi <stefanha@redhat.com>

On 08/14/2013 01:57 PM, Alex Bligh wrote:
> I don't agree. The penalty for a qcow2 suffering a false positive on
> a change to a backing file is that the VM can no longer boot. The
> penalty for your cache suffering a false positive is that the
> VM boots marginally slower. Moreover, it is expected behaviour that
> you CAN change a backing file if there are no r/w images based on
> it. Your cache changes that assumption.

That is right. So when there is a change in the backing file, either the
cache should be invalidated or the changes should be propagated to the
cache image. If changes to the backing image are not frequent, then
invalidation is the simpler approach. In any case, there should be a
mechanism to detect this. I assume it is also undesirable for a VM to
see stale data when booting from a cow image twice.

Kaveh