From mboxrd@z Thu Jan  1 00:00:00 1970
Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43)
	id 1KL3gA-00058m-9n
	for qemu-devel@nongnu.org; Mon, 21 Jul 2008 18:16:26 -0400
Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43)
	id 1KL3g8-00057G-Lf
	for qemu-devel@nongnu.org; Mon, 21 Jul 2008 18:16:25 -0400
Received: from [199.232.76.173] (port=59709 helo=monty-python.gnu.org)
	by lists.gnu.org with esmtp (Exim 4.43) id 1KL3g8-00057A-FH
	for qemu-devel@nongnu.org; Mon, 21 Jul 2008 18:16:24 -0400
Received: from wr-out-0506.google.com ([64.233.184.228]:39746)
	by monty-python.gnu.org with esmtp (Exim 4.60)
	(envelope-from <anthony@codemonkey.ws>) id 1KL3g8-0004NC-5l
	for qemu-devel@nongnu.org; Mon, 21 Jul 2008 18:16:24 -0400
Received: by wr-out-0506.google.com with SMTP id c46so1043060wra.18
	for <qemu-devel@nongnu.org>; Mon, 21 Jul 2008 15:16:22 -0700 (PDT)
Message-ID: <48850A99.7070005@codemonkey.ws>
Date: Mon, 21 Jul 2008 17:15:53 -0500
From: Anthony Liguori <anthony@codemonkey.ws>
MIME-Version: 1.0
Subject: Re: [Qemu-devel] qcow2 - safe on kill?  safe on power fail?
References: <47CF0E0C.9030807@quinthar.com>
	<47CF16C5.6040102@codemonkey.ws>	<20080721181031.GA31773@shareable.org>	<4884E6F1.5020205@codemonkey.ws>
	<jeabgagaoc.fsf@sykes.suse.de>
In-Reply-To: <jeabgagaoc.fsf@sykes.suse.de>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Reply-To: qemu-devel@nongnu.org
List-Id: qemu-devel.nongnu.org
List-Unsubscribe: <http://lists.nongnu.org/mailman/listinfo/qemu-devel>,
	<mailto:qemu-devel-request@nongnu.org?subject=unsubscribe>
List-Archive: <http://lists.gnu.org/pipermail/qemu-devel>
List-Post: <mailto:qemu-devel@nongnu.org>
List-Help: <mailto:qemu-devel-request@nongnu.org?subject=help>
List-Subscribe: <http://lists.nongnu.org/mailman/listinfo/qemu-devel>,
	<mailto:qemu-devel-request@nongnu.org?subject=subscribe>
To: qemu-devel@nongnu.org

Andreas Schwab wrote:
> Anthony Liguori <anthony@codemonkey.ws> writes:
>
>   
>> The only ways that you can cause corruption is if the QCOW2 sector
>> allocation code is faulty (and you would be screwed no matter what here)
>> or if you issue a SIGTERM/SIGKILL that interrupts the code while it's
>> allocating a new sector.
>>     
>
> Blocking SIGTERM until the allocation is finished could close that hole.
>   

Seems like a band-aid to me as SIGKILL is still an issue.  Plus it would 
involve modifying all disk formats, not just QCOW2.  I'd rather see 
proper journal support added to QCOW2 myself.

Regards,

Anthony Liguori

> Andreas.
>
>