From: Kevin Wolf <kwolf@redhat.com>
To: qemu-block@nongnu.org
Cc: kwolf@redhat.com, mreitz@redhat.com, eblake@redhat.com,
qemu-devel@nongnu.org
Subject: [Qemu-devel] [RFC PATCH 00/11] qcow2: External data files
Date: Thu, 31 Jan 2019 18:55:38 +0100 [thread overview]
Message-ID: <20190131175549.11691-1-kwolf@redhat.com> (raw)
There are use cases where raw images are given (e.g. existing physical
disks), but advanced features like dirty bitmaps or backing files are
wanted that require use of a proper image format like qcow2.
This series adds an incompatible feature bit to qcow2 which allows to
use an external data file: Metadata is kept in the qcow2 file like
usual, but guest data is written to an external file. Clusters in the
data file are not reference counted, instead we use a flat layout where
host cluster offset == guest cluster offset. The external data file is
therefore readable as a raw image (though writing to it invalidates the
associated qcow2 metadata). Features that require refcounting such as
internal snapshots or compression are not supposed in such setups.
There are a few reasons why this is still RFC:
- The resulting code passes qemu-iotests, so we don't regress on normal
qcow2 files, but testing with external data files is still minimal
(converting an existing image and confirming it reads back unmodified;
installing a guest OS and making sure it boots). We need at least some
qemu-iotests cases.
- QAPI documentation is missing
- Discard isn't passed through to the data file yet
- s->image_data_file isn't correct, it gets the value from the attached
node rather than just from the image file. This means that on header
updates we might be writing "back" a path that wasn't there before.
- Probably something else I just can't remember now :-)
Kevin Wolf (11):
qcow2: Extend spec for external data files
qcow2: Basic definitions for external data files
qcow2: Pass bs to qcow2_get_cluster_type()
qcow2: Prepare qcow2_get_cluster_type() for external data file
qcow2: Prepare count_contiguous_clusters() for external data file
qcow2: Don't assume 0 is an invalid cluster offset
qcow2: External file I/O
qcow2: Add basic data-file infrastructure
qcow2: Creating images with external data file
qcow2: Store data file name in the image
qcow2: Add data file to ImageInfoSpecificQCow2
qapi/block-core.json | 5 +-
docs/interop/qcow2.txt | 19 ++++-
block/qcow2.h | 40 +++++++--
include/block/block_int.h | 1 +
block/qcow2-bitmap.c | 7 +-
block/qcow2-cache.c | 6 +-
block/qcow2-cluster.c | 144 +++++++++++++++++++-------------
block/qcow2-refcount.c | 40 ++++++---
block/qcow2-snapshot.c | 7 +-
block/qcow2.c | 166 ++++++++++++++++++++++++++++++++++---
tests/qemu-iotests/031.out | 8 +-
tests/qemu-iotests/036.out | 4 +-
tests/qemu-iotests/061.out | 14 ++--
tests/qemu-iotests/082.out | 27 ++++++
14 files changed, 372 insertions(+), 116 deletions(-)
--
2.20.1
next reply other threads:[~2019-01-31 17:56 UTC|newest]
Thread overview: 46+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-01-31 17:55 Kevin Wolf [this message]
2019-01-31 17:55 ` [Qemu-devel] [RFC PATCH 01/11] qcow2: Extend spec for external data files Kevin Wolf
2019-01-31 18:43 ` Eric Blake
2019-01-31 21:44 ` [Qemu-devel] [Qemu-block] " Nir Soffer
2019-02-01 10:29 ` Kevin Wolf
2019-02-01 10:21 ` [Qemu-devel] " Kevin Wolf
2019-02-01 16:17 ` Eric Blake
2019-02-01 16:53 ` Kevin Wolf
2019-01-31 17:55 ` [Qemu-devel] [RFC PATCH 02/11] qcow2: Basic definitions " Kevin Wolf
2019-01-31 17:55 ` [Qemu-devel] [RFC PATCH 03/11] qcow2: Pass bs to qcow2_get_cluster_type() Kevin Wolf
2019-01-31 17:55 ` [Qemu-devel] [RFC PATCH 04/11] qcow2: Prepare qcow2_get_cluster_type() for external data file Kevin Wolf
2019-01-31 17:55 ` [Qemu-devel] [RFC PATCH 05/11] qcow2: Prepare count_contiguous_clusters() " Kevin Wolf
2019-01-31 17:55 ` [Qemu-devel] [RFC PATCH 06/11] qcow2: Don't assume 0 is an invalid cluster offset Kevin Wolf
2019-02-18 23:13 ` Max Reitz
2019-02-19 8:45 ` Kevin Wolf
2019-02-22 14:09 ` Max Reitz
2019-01-31 17:55 ` [Qemu-devel] [RFC PATCH 07/11] qcow2: External file I/O Kevin Wolf
2019-02-18 23:36 ` Max Reitz
2019-01-31 17:55 ` [Qemu-devel] [RFC PATCH 08/11] qcow2: Add basic data-file infrastructure Kevin Wolf
2019-01-31 18:44 ` Eric Blake
2019-02-01 10:30 ` Kevin Wolf
2019-02-18 23:57 ` Max Reitz
2019-02-19 8:51 ` Kevin Wolf
2019-02-22 14:12 ` Max Reitz
2019-02-22 15:38 ` Kevin Wolf
2019-02-22 15:45 ` Max Reitz
2019-01-31 17:55 ` [Qemu-devel] [RFC PATCH 09/11] qcow2: Creating images with external data file Kevin Wolf
2019-01-31 17:55 ` [Qemu-devel] [RFC PATCH 10/11] qcow2: Store data file name in the image Kevin Wolf
2019-01-31 22:39 ` Nir Soffer
2019-02-19 0:18 ` Max Reitz
2019-02-19 9:04 ` Kevin Wolf
2019-02-22 14:16 ` Max Reitz
2019-02-22 15:35 ` Kevin Wolf
2019-02-22 15:43 ` Max Reitz
2019-02-22 16:06 ` Kevin Wolf
2019-02-22 16:22 ` Max Reitz
2019-01-31 17:55 ` [Qemu-devel] [RFC PATCH 11/11] qcow2: Add data file to ImageInfoSpecificQCow2 Kevin Wolf
2019-02-19 0:47 ` Max Reitz
2019-02-19 9:17 ` Kevin Wolf
2019-02-19 15:49 ` Eric Blake
2019-02-22 13:51 ` Max Reitz
2019-02-22 15:57 ` Kevin Wolf
2019-02-22 16:13 ` Max Reitz
2019-02-22 16:29 ` Kevin Wolf
2019-01-31 21:39 ` [Qemu-devel] [Qemu-block] [RFC PATCH 00/11] qcow2: External data files Nir Soffer
2019-02-19 0:49 ` [Qemu-devel] " Max Reitz
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=20190131175549.11691-1-kwolf@redhat.com \
--to=kwolf@redhat.com \
--cc=eblake@redhat.com \
--cc=mreitz@redhat.com \
--cc=qemu-block@nongnu.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).