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

[Avi Kivity <avi@qumranet.com>]

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.