qemu-devel.nongnu.org archive mirror
 help / color / mirror / Atom feed
From: Jamie Lokier <jamie@shareable.org>
To: qemu-devel@nongnu.org
Subject: Re: [Qemu-devel] qcow2 - safe on kill?  safe on power fail?
Date: Tue, 22 Jul 2008 21:04:54 +0100	[thread overview]
Message-ID: <20080722200450.GA27753@shareable.org> (raw)
In-Reply-To: <4886316E.4080601@qumranet.com>

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	other threads:[~2008-07-22 19:42 UTC|newest]

Thread overview: 26+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2008-03-05 21:18 [Qemu-devel] Signal handling and qcow2 image corruption David Barrett
2008-03-05 21:55 ` Anthony Liguori
2008-03-05 23:48   ` David Barrett
2008-03-06  6:57   ` Avi Kivity
2008-07-21 18:10   ` [Qemu-devel] qcow2 - safe on kill? safe on power fail? Jamie Lokier
2008-07-21 19:43     ` Anthony Liguori
2008-07-21 21:26       ` Jamie Lokier
2008-07-21 22:14         ` Anthony Liguori
2008-07-21 23:47           ` Jamie Lokier
2008-07-22  6:06           ` Avi Kivity
2008-07-22 14:08             ` Anthony Liguori
2008-07-22 14:46               ` Jamie Lokier
2008-07-22 19:11               ` Avi Kivity
2008-07-22 14:32             ` Jamie Lokier
2008-07-21 22:00       ` Andreas Schwab
2008-07-21 22:15         ` Anthony Liguori
2008-07-21 22:22           ` David Barrett
2008-07-21 22:50             ` Anthony Liguori
2008-07-22  6:07           ` Avi Kivity
2008-07-22 14:11             ` Anthony Liguori
2008-07-22 14:36               ` Avi Kivity
2008-07-22 16:16                 ` Jamie Lokier
2008-07-22 19:13                   ` Avi Kivity
2008-07-22 20:04                     ` Jamie Lokier [this message]
2008-07-22 21:25                       ` Avi Kivity
2008-07-22 14:22             ` Jamie Lokier

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20080722200450.GA27753@shareable.org \
    --to=jamie@shareable.org \
    --cc=qemu-devel@nongnu.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).