From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1KLNJ6-00081t-Ck for qemu-devel@nongnu.org; Tue, 22 Jul 2008 15:13:56 -0400 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1KLNJ5-000814-0F for qemu-devel@nongnu.org; Tue, 22 Jul 2008 15:13:56 -0400 Received: from [199.232.76.173] (port=36186 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1KLNJ4-00080v-Hm for qemu-devel@nongnu.org; Tue, 22 Jul 2008 15:13:54 -0400 Received: from il.qumranet.com ([212.179.150.194]:59802) by monty-python.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1KLNJ3-0005YR-Dj for qemu-devel@nongnu.org; Tue, 22 Jul 2008 15:13:53 -0400 Message-ID: <4886316E.4080601@qumranet.com> Date: Tue, 22 Jul 2008 22:13:50 +0300 From: Avi Kivity 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> <48850A99.7070005@codemonkey.ws> <48857926.5020708@qumranet.com> <4885EA8B.5050908@codemonkey.ws> <4885F068.2060902@qumranet.com> <20080722161607.GA22535@shareable.org> In-Reply-To: <20080722161607.GA22535@shareable.org> 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: , List-Archive: List-Post: List-Help: List-Subscribe: , To: qemu-devel@nongnu.org Jamie Lokier wrote: >> It's a simple matter of allocating, making sure the allocation is on >> disk, and recording that allocation in the tables. >> > > The simple implementations are only safe if sector writes are atomic. > > Opinions from Google seem divided about when you can assume that, > especially when the underlying file or device is not directly mapped > to disk sectors. > That's worrying. I guess always-allocate-on-write solves that (with versioned roots in well-known places), but that's not qcow2 any more -- it's btrfs. And given that btrfs ought to allow file-level snapshots, perhaps the direction should be raw files on top of btrfs (which could be extended to do block sharing, yay!) -- I have a truly marvellous patch that fixes the bug which this signature is too narrow to contain.