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: Jamie Lokier
Subject: Re: [Qemu-devel] qcow2 - safe on kill? safe on power fail?
Date: Tue, 22 Jul 2008 21:04:54 +0100
User-agent: Mutt/1.5.13 (2006-08-11)

Avi Kivity 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.

Fair. Simple journalling with checksumed log records also solves the
problem without being half as clever - and probably easy to retrofit
to qcow2, without breaking backward compatibility.  (Old qemus would
ignore the journal.)

> 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?

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.

Userspace btrfs-in-a-file library would be ideal, for cross-platform
support, but I don't see it happening.

You can do raw, sparse files on ext3 or any other unix filesystem.
They are about as compact as qcow2, if you ignore compression.

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.

The FIEMAP interface may solve it, generically on all Linux
filesystem, if copying tools are updated to use it.

-- Jamie




reply via email to

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