From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([140.186.70.92]:38118) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1QoNcA-0004lL-7K for qemu-devel@nongnu.org; Tue, 02 Aug 2011 18:39:07 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1QoNc9-0005UF-93 for qemu-devel@nongnu.org; Tue, 02 Aug 2011 18:39:06 -0400 Received: from mx1.redhat.com ([209.132.183.28]:56874) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1QoNc8-0005UB-W0 for qemu-devel@nongnu.org; Tue, 02 Aug 2011 18:39:05 -0400 Message-ID: <4E387C82.8080908@redhat.com> Date: Wed, 03 Aug 2011 01:38:58 +0300 From: Avi Kivity MIME-Version: 1.0 References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [Qemu-devel] [PATCH v3] XBZRLE delta for live migration of large memory apps List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Alexander Graf Cc: Kevin Wolf , Stefan Hajnoczi , "Shribman, Aidan" , qemu-devel Developers On 08/02/2011 05:01 PM, Alexander Graf wrote: > So if I understand correctly, this enabled delta updates for dirty pages? Would it be possible to do the same on the block layer, so that VM backing file data could potentially save the new information as delta over the old block? Especially with metadata updates, that could save quite some disk space. Just use a smaller block size. While you could save even more when considering metadata, I think the bulk of the gain would be in actual data. -- I have a truly marvellous patch that fixes the bug which this signature is too narrow to contain.