From: Stefan Hajnoczi <stefanha@linux.vnet.ibm.com>
To: qemu-devel@nongnu.org
Cc: Kevin Wolf <kwolf@redhat.com>,
Stefan Hajnoczi <stefanha@linux.vnet.ibm.com>
Subject: [Qemu-devel] [PATCH v5 0/8] block: generic copy-on-read
Date: Mon, 28 Nov 2011 16:08:46 +0000 [thread overview]
Message-ID: <1322496527-19019-1-git-send-email-stefanha@linux.vnet.ibm.com> (raw)
[Kevin: As requested, I am only sending Patch 4 and not the rest of the patches
since they are unchanged and already applied to your block tree.]
The new -drive copy-on-read=on|off feature populates the image file with data
from the backing file on read. This is useful when accessing images backed
over a slow medium (e.g. http over internet). All read data will be stored in
the local image file so it does not need to be fetched again in the future.
This series is a prerequisite for the image streaming feature, which uses
copy-on-read to populate the image file in the background while the VM is
running. However, the copy-on-read feature is useful on its own.
Copy-on-read is implemented by checking whether or not data is allocated in the
image file before reading it. If data is not allocated then it needs to be
read and written back to the image file.
The tricky bit is avoiding races with other I/O requests. These patches add
request tracking to BlockDriverState so that the list of pending requests is
available. Copy-on-read prevents races by serializing overlapping requests.
Finally, there is a performance impact when enabling this feature since an
additional write is performed. Serializing overlapping requests also means
that I/O patterns where multiple requests access the same cluster will see a
loss in parallelism. Perhaps we can be smarter about preventing corruption in
the future and win back some performance.
v5:
* Fix refcount on startup [Kevin]
v4:
* No changes, sorry for the spam v3 emails that were sent out
v3:
* Improve wait_for_overlapping_requests() comment [Kevin]
v2:
* Based on bdrv_co_is_allocated patch series - now safe in coroutine context
* Use QEMU_ALIGN_DOWN/UP() macros for copy-on-read cluster calculations [Zhi Yong]
* Reset bs->copy_on_read on bdrv_close() [Kevin]
* Refcount bs->copy_on_read so it doesn't get clobbered by multiple users [Marcelo]
* Use bool instead of int where appropriate [Kevin]
* Use compound literal assignment to ensure BdrvTrackedRequest fields always get zeroed [Kevin]
* Comment rationale for copy-on-read bounce buffer [Kevin]
Stefan Hajnoczi (1):
block: add interface to toggle copy-on-read
block.c | 22 ++++++++++++++++++++++
block.h | 4 ++++
block_int.h | 2 ++
3 files changed, 28 insertions(+), 0 deletions(-)
--
1.7.7.3
next reply other threads:[~2011-11-28 16:09 UTC|newest]
Thread overview: 3+ messages / expand[flat|nested] mbox.gz Atom feed top
2011-11-28 16:08 Stefan Hajnoczi [this message]
2011-11-28 16:08 ` [Qemu-devel] [PATCH v5 4/8] block: add interface to toggle copy-on-read Stefan Hajnoczi
2011-11-30 9:38 ` Kevin Wolf
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=1322496527-19019-1-git-send-email-stefanha@linux.vnet.ibm.com \
--to=stefanha@linux.vnet.ibm.com \
--cc=kwolf@redhat.com \
--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).