From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:51931) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1V9ZdS-0006B5-Dg for qemu-devel@nongnu.org; Wed, 14 Aug 2013 07:53:12 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1V9ZdM-0005iB-FU for qemu-devel@nongnu.org; Wed, 14 Aug 2013 07:53:06 -0400 Received: from mx1.redhat.com ([209.132.183.28]:26582) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1V9ZdM-0005i1-6s for qemu-devel@nongnu.org; Wed, 14 Aug 2013 07:53:00 -0400 Date: Wed, 14 Aug 2013 19:52:48 +0800 From: Fam Zheng Message-ID: <20130814115248.GA22291@localhost.localdomain> References: <1376413436-5424-1-git-send-email-kaveh@cs.vu.nl> <8737CB0DA803476059F56AF5@nimrod.local> <520B69D5.3070505@cs.vu.nl> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <520B69D5.3070505@cs.vu.nl> Subject: Re: [Qemu-devel] [PATCH] Introduce cache images for the QCOW2 format Reply-To: famz@redhat.com List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Kaveh Razavi Cc: Kevin Wolf , Stefan Hajnoczi , qemu-devel@nongnu.org, Alex Bligh On Wed, 08/14 13:28, Kaveh Razavi wrote: > On 08/14/2013 12:53 AM, Alex Bligh wrote: > > What is this cache keyed on and how is it invalidated? Let's say a > > 2 VM on node X boot with backing file A. The first populates the cache, > > and the second utilises the cache. I then stop both VMs, delete > > the derived disks, and change the contents of the backing file. I then > > boot a VM using the changed backing file on node X and node Y. I think > > node Y is going to get the clean backing file. However, how does node > > X know not to use the cache? Would it not be a good idea to check > > (at least) the inode number and the mtime of the backing file correspond > > with values saved in the cache, and if not the same then ignore the > > cache? > > You could argue the same for normal qcow2. Start from a cow image with a > backing image, stop the VM. Start another VM, modifying the backing > image directly. Start the VM again, this time from the cow image, and > the VM can see stale data in the stored data clusters of the cow image. > > The idea is once a user registers an image to a cloud middleware, it is > assigned an image ID. As long as the middleware assigns a cache to the > backing image with the same ID, there is no possibility to read stale > data. If it is desired to have some sort of check at the qemu level, it > should be implemented in the qcow2 directly for all backing files and > this extension will benefit from it too. > Yes, this one sounds good to have. VMDK and VHDX have this kind of backing file status validation. Thanks. Fam