From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([140.186.70.92]:35865) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ROn9e-0002TQ-QY for qemu-devel@nongnu.org; Fri, 11 Nov 2011 04:12:11 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1ROn9d-0005qO-LU for qemu-devel@nongnu.org; Fri, 11 Nov 2011 04:12:10 -0500 Received: from mx1.redhat.com ([209.132.183.28]:36160) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ROn9d-0005qK-Ch for qemu-devel@nongnu.org; Fri, 11 Nov 2011 04:12:09 -0500 Message-ID: <4EBCE79E.6000209@redhat.com> Date: Fri, 11 Nov 2011 10:15:10 +0100 From: Kevin Wolf MIME-Version: 1.0 References: <4EBC683C.7090700@codemonkey.ws> <4EBCC051.1060705@linux.vnet.ibm.com> In-Reply-To: <4EBCC051.1060705@linux.vnet.ibm.com> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: Re: [Qemu-devel] Storage requirements for live migration List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Mark Wu Cc: Stefan Hajnoczi , Juan Quintela , qemu-devel , Avi Kivity , Christoph Hellwig Am 11.11.2011 07:27, schrieb Mark Wu: > On 11/11/2011 08:11 AM, Anthony Liguori wrote: >> I did a brain dump of my understanding of the various storage >> requirements for live migration. I think it's accurate but I may have >> misunderstand some details so I would appreciate review. >> >> I think given sections (1) and (2), the only viable thing is to >> require cache=none unless we get new interfaces to flush caches. > I have two questions: > 1. why is "cache=writethrough" not reliable? "O_DSYNC" can guarantee > data is written on disk before the operation is ultimately completed. > Even if there's synchronization from memory to disk still on-going when > migration happens, we needn't care about the dirty pages in host memory > either because the queued request will be re-executed on destination > host. So I think it's reliable too. Do I miss anything? The problem is about reading. The destination host reads some pieces of information during its initialisation, which may later be changed on the host. After the migration has completed, the destination must not use the old data that it read previously and that might be in its cache, but it must access the storage. O_DSYNC doesn't help with that, as reading still uses the cache there. Kevin