From mboxrd@z Thu Jan  1 00:00:00 1970
Received: from eggs.gnu.org ([2001:4830:134:3::10]:45725)
	by lists.gnu.org with esmtp (Exim 4.71)
	(envelope-from <alex@alex.org.uk>) id 1V9Np8-0001xt-5c
	for qemu-devel@nongnu.org; Tue, 13 Aug 2013 19:16:24 -0400
Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71)
	(envelope-from <alex@alex.org.uk>) id 1V9Np7-0008UM-6g
	for qemu-devel@nongnu.org; Tue, 13 Aug 2013 19:16:22 -0400
Received: from mail.avalus.com ([2001:41c8:10:1dd::10]:48366)
	by eggs.gnu.org with esmtp (Exim 4.71)
	(envelope-from <alex@alex.org.uk>) id 1V9Np7-0008UI-0g
	for qemu-devel@nongnu.org; Tue, 13 Aug 2013 19:16:21 -0400
Date: Wed, 14 Aug 2013 00:16:06 +0100
From: Alex Bligh <alex@alex.org.uk>
Message-ID: <00D703C3BB04779367573E57@nimrod.local>
In-Reply-To: <1376413436-5424-1-git-send-email-kaveh@cs.vu.nl>
References: <1376413436-5424-1-git-send-email-kaveh@cs.vu.nl>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
Subject: Re: [Qemu-devel] [PATCH] Introduce cache images for the QCOW2 format
Reply-To: Alex Bligh <alex@alex.org.uk>
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: Kaveh Razavi <kaveh@cs.vu.nl>, qemu-devel@nongnu.org
Cc: Kevin Wolf <kwolf@redhat.com>, Alex Bligh <alex@alex.org.uk>, Stefan Hajnoczi <stefanha@redhat.com>



--On 13 August 2013 19:03:56 +0200 Kaveh Razavi <kaveh@cs.vu.nl> wrote:

>  Also,
> simultaneously booting VMs from more than one VM image creates a
> bottleneck at the storage device of the base image, if the storage
> device does not fair well with the random access pattern that happens
> during booting.

Additional question (sorry for spitting them)

The above para implies you intend one cache file to be shared by
two VMs booting from the same backing image on the same node.
If that's true, how do you protect yourself from the following:

    VM1                                         VM2

1.  Read rq for block 1234

2.  Start writing block 1234 to cache file

3.                                              Read fq for blk 1234

4.                                              Read blk 1234 from
                                                cache file

5.  Finish writing block 1234 to cache file


As far as I can see VM1 could read an incomplete write from
the cache file.

Further, unless you're opening these files O_DIRECT, how do you
know half the writes from VM1 won't be sitting dirty in the page
cache when you read using VM2?

-- 
Alex Bligh