qemu-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Qemu-devel] qcow2 - safe on kill? safe on power fail?


From: Avi Kivity
Subject: Re: [Qemu-devel] qcow2 - safe on kill? safe on power fail?
Date: Wed, 23 Jul 2008 00:25:43 +0300
User-agent: Thunderbird 2.0.0.14 (X11/20080501)

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.





reply via email to

[Prev in Thread] Current Thread [Next in Thread]