openstack
/
nova
Code Issues Proposed changes
OpenStack Compute (Nova)
53,695 Commits 9 Branches 84 Tags 1.6 GiB
Python 97.7%
Smarty 2.2%
Shell 0.1%
Go to file
Kashyap Chamarthy e7b64eaad8 qemu: Make disk image conversion dramatically faster 
tl;dr: Use 'writeback' instead of 'writethrough' as the cache mode of
the target image for `qemu-img convert`.  Two reasons: (a) if the image
conversion completes succesfully, then 'writeback' calls fsync() to
safely write data to the physical disk; and (b) 'writeback' makes the
image conversion a _lot_ faster.

Back-of-the-envelope "benchmark" (on an SSD)
--------------------------------------------

(Ran both the tests thrice each; version: qemu-img-2.11.0)

With 'writethrough':

    $> time (qemu-img convert -t writethrough -f qcow2 -O raw \
            Fedora-Cloud-Base-29.qcow2 Fedora-Cloud-Base-29.raw)
    real    1m43.470s
    user    0m8.310s
    sys     0m3.661s

With 'writeback':

    $> time (qemu-img convert -t writeback  -f qcow2 -O raw \
            Fedora-Cloud-Base-29.qcow2 5-Fedora-Cloud-Base-29.raw)

    real    0m7.390s
    user    0m5.179s
    sys     0m1.780s

I.e. ~103 seconds of elapsed wall-clock time for 'writethrough' vs. ~7
seconds for 'writeback' -- IOW, 'writeback' is nearly _15_ times faster!

Details
-------

Nova commit e6ce9557f8 ("qemu-img do not
use cache=none if no O_DIRECT support") was introduced to make instances
boot on filesystems that don't support 'O_DIRECT' (which bypasses the
host page cache and flushes data directly to the disk), such as 'tmpfs'.
In doing so it introduced the 'writethrough' cache for the target image
for `qemu-img convert`.

This patch proposes to change that to 'writeback'.

Let's addresses the 'safety' concern:

  "What about data integrity in the event of a host crash (especially
   on shared file systems such as NFS)?"

Answer: If the host crashes mid-way during image conversion, then
neither "data integrity" nor the cache mode in use matters.  But if the
image conversion completes _succesfully_, then 'writeback' will safely
write the data to the physical disk, just as 'writethough' does.

So we are as safe as we can, but with the extra benefit of image
conversion being _much_ faster.

        * * *

The `qemu-img convert` command defaults to 'cache=writeback' for the
source image.  And 'cache=unsafe' for the target, because if `qemu-img`
"crashes during the conversion, the user will throw away the broken
output file anyway and start over"[1].  And `qemu-img convert`
supports[2] fsync() for the target image since QEMU 1.1 (2012).

[1] https://git.qemu.org/?p=qemu.git;a=commitdiff;h=1bd8e175
    -- "qemu-img convert: Use cache=unsafe for output image"
[2] https://git.qemu.org/?p=qemu.git;a=commitdiff;h=80ccf93b
    -- "qemu-img: let 'qemu-img convert' flush data"

Closes-Bug: #1818847

Change-Id: I574be2b629aaff23556e25f8db0d740105be6f07
Signed-off-by: Kashyap Chamarthy <kchamart@redhat.com>
Looks-good-to-me'd-by: Kevin Wolf <kwolf@redhat.com>
 		2019-03-18 14:53:39 -05:00
api-guide/source Merge "Remove wrong description for auto resize confirm" 2019-03-04 14:04:35 +00:00
api-ref/source api-ref: typo service.disable_reason 2019-03-05 16:58:13 +08:00
devstack Remove the CachingScheduler 2018-10-18 17:55:36 -04:00
doc doc: Fix a typo 2019-03-11 17:45:25 +09:00
etc/nova Add oslo.privsep to config-generator list 2019-03-01 16:43:21 +00:00
gate update gate test for removal of force evacuate 2019-03-08 16:31:31 +00:00
nova qemu: Make disk image conversion dramatically faster 2019-03-18 14:53:39 -05:00
playbooks/legacy Merge "Do not run tempest.scenario.test_network* tests in nova-next" 2019-03-09 14:18:16 +00:00
releasenotes qemu: Make disk image conversion dramatically faster 2019-03-18 14:53:39 -05:00
tools Make Xen code py3-compatible 2018-08-10 20:04:19 +00:00
.coveragerc Remove nova/openstack/* from .coveragerc 2016-10-12 16:20:49 -04:00
.gitignore Remove Placement API reference 2018-11-28 03:38:41 +00:00
.gitreview Add .gitreview config file for gerrit. 2011-10-24 15:07:19 -04:00
.mailmap Add mailmap entry 2014-05-07 12:14:26 -07:00
.stestr.conf Finish stestr migration 2017-11-24 16:51:12 -05:00
.zuul.yaml Merge "Do not run tempest.scenario.test_network* tests in nova-next" 2019-03-09 14:18:16 +00:00
CONTRIBUTING.rst Update links in documents 2018-01-12 17:05:11 +08:00
HACKING.rst Document how to make tests log at DEBUG level 2019-02-13 20:46:01 +00:00
LICENSE initial commit 2010-05-27 23:05:26 -07:00
MAINTAINERS Fix broken URLs 2017-09-07 15:42:31 +02:00
README.rst Docs: modernise links 2018-03-24 20:27:11 +08:00
babel.cfg Get rid of distutils.extra. 2012-02-08 19:30:39 -08:00
bindep.txt Merge "Bindep does not catch missing libpcre3-dev on Ubuntu" 2018-02-14 07:31:09 +00:00
lower-constraints.txt Merge "Convert driver supported capabilities to compute node provider traits" 2019-03-05 09:50:12 +00:00
requirements.txt Merge "Convert driver supported capabilities to compute node provider traits" 2019-03-05 09:50:12 +00:00
setup.cfg Update mailinglist from dev to discuss 2018-12-05 09:44:35 +08:00
setup.py Updated from global requirements 2017-03-02 11:50:48 +00:00
test-requirements.txt Fix ironic client ironic_url deprecation warning 2018-10-24 17:59:10 +02:00
tox.ini Merge "Fix deps for api-samples tox env" 2019-02-15 02:18:17 +00:00

README.rst

Team and repository tags

image

OpenStack Nova

OpenStack Nova provides a cloud computing fabric controller, supporting a wide variety of compute technologies, including: libvirt (KVM, Xen, LXC and more), Hyper-V, VMware, XenServer, OpenStack Ironic and PowerVM.

Use the following resources to learn more.

API

To learn how to use Nova's API, consult the documentation available online at:

For more information on OpenStack APIs, SDKs and CLIs in general, refer to:

Operators

To learn how to deploy and configure OpenStack Nova, consult the documentation available online at:

In the unfortunate event that bugs are discovered, they should be reported to the appropriate bug tracker. If you obtained the software from a 3rd party operating system vendor, it is often wise to use their own bug tracker for reporting problems. In all other cases use the master OpenStack bug tracker, available at:

Developers

For information on how to contribute to Nova, please see the contents of the CONTRIBUTING.rst.

Any new code must follow the development guidelines detailed in the HACKING.rst file, and pass all unit tests.

Further developer focused documentation is available at:

Other Information

During each Summit and Project Team Gathering, we agree on what the whole community wants to focus on for the upcoming release. The plans for nova can be found at: