From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1KLPMk-0008Fn-RI for qemu-devel@nongnu.org; Tue, 22 Jul 2008 17:25:50 -0400 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1KLPMj-0008Ew-B5 for qemu-devel@nongnu.org; Tue, 22 Jul 2008 17:25:50 -0400 Received: from [199.232.76.173] (port=54516 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1KLPMj-0008EV-60 for qemu-devel@nongnu.org; Tue, 22 Jul 2008 17:25:49 -0400 Received: from il.qumranet.com ([212.179.150.194]:41356) by monty-python.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1KLPMi-0005Vu-0O for qemu-devel@nongnu.org; Tue, 22 Jul 2008 17:25:48 -0400 Message-ID: <48865057.4020608@qumranet.com> Date: Wed, 23 Jul 2008 00:25:43 +0300 From: Avi Kivity MIME-Version: 1.0 Subject: Re: [Qemu-devel] qcow2 - safe on kill? safe on power fail? References: <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> <4886316E.4080601@qumranet.com> <20080722200450.GA27753@shareable.org> In-Reply-To: <20080722200450.GA27753@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: > >> 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!) >> > > Block/extent sharing would be a nice bonus :-) > > Does btrfs work on other platforms than Linux? > > There's a Solaris port called zfs, and a bsd port called WAFL. > Also, is btrfs as good as the hype, in respect of things like fsync, > barriers, cache=off consistency etc. which we've talked about? Maybe, > but I wouldn't assume it. > It better be, as it's coming from oracle. O_DIRECT and barriers are their bread and butter (fs). > > You can do raw, sparse files on ext3 or any other unix filesystem. > They are about as compact as qcow2, if you ignore compression. > > Except that you lose snapshot support, etc. > The real big problem I found with sparse files is that copying them > locally, or copying them to another machine (e.g. with rsync) is > *incredibly* slow because it's so slow to scan the sparse regions, and > this gets really slow if you have, say, a 100GB virtual disk (5GB > used, rest to grow into). "rsync --sparse" even bizarrely transmits a > lot of zero data over the network, or spends an age compressing it. > > btrfs flat files will have the same problem. > There was some talk about an API to discover unallocated regions. > The FIEMAP interface may solve it, generically on all Linux > filesystem, if copying tools are updated to use it. > Like that, but better. -- I have a truly marvellous patch that fixes the bug which this signature is too narrow to contain.