From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from [140.186.70.92] (port=42406 helo=eggs.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1PtcpR-0005U8-Br for qemu-devel@nongnu.org; Sun, 27 Feb 2011 04:22:18 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1PtcpM-0002OG-HK for qemu-devel@nongnu.org; Sun, 27 Feb 2011 04:22:13 -0500 Received: from mx1.redhat.com ([209.132.183.28]:1922) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1PtcpM-0002Nw-81 for qemu-devel@nongnu.org; Sun, 27 Feb 2011 04:22:08 -0500 Message-ID: <4D6A17B9.2020303@redhat.com> Date: Sun, 27 Feb 2011 11:22:01 +0200 From: Avi Kivity MIME-Version: 1.0 Subject: Re: [Qemu-devel] Re: [patch 2/3] Add support for live block copy References: <4D642181.4080509@codemonkey.ws> <20110222210735.GA9372@amt.cnet> <4D64266A.3060106@codemonkey.ws> <20110222230935.GA11082@amt.cnet> <4D644343.4050800@codemonkey.ws> <4D65051A.6070707@redhat.com> <20110223174917.GA4630@amt.cnet> <4D661DA2.2050102@redhat.com> <20110224151411.GA3794@amt.cnet> <4D667914.4090602@redhat.com> <20110224163933.GA10165@amt.cnet> <4D669953.40808@codemonkey.ws> In-Reply-To: <4D669953.40808@codemonkey.ws> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit List-Id: qemu-devel.nongnu.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Anthony Liguori Cc: Jes.Sorensen@redhat.com, Marcelo Tosatti , qemu-devel@nongnu.org On 02/24/2011 07:45 PM, Anthony Liguori wrote: > > Yeah, it feels like we're introducing QEMU level RAID. We already did, with sheepdog (well the RAID code is really outside qemu itself). > At what point are we going to add RAID5 support and not just RAID1. > And it certainly begs the question of whether this use-case can be > satisfied by just using Linux's RAID stack leaving one drive degraded > and enabling the other drive when the time comes to fail over. The magic word is btrfs, we already have atomic live copy outside qemu ('cp --reflink'). If you also want an atomic switch you have to move it inside qemu so you can switch to the new file. Using one of the Linux RAID-1 implementations (md, dm, or drbd) is also possible but these are really designed for block devices, not files. -- error compiling committee.c: too many arguments to function