Add support for 'l2-cache-size' (a QCOW2 run time option for metadata cache size) for drives

Bug #1509304 reported by Tim Bell
18
This bug affects 2 people
Affects Status Importance Assigned to Milestone
OpenStack Compute (nova)
Invalid
Undecided
Unassigned

Bug Description

QCOW2 performance can be significantly improved by setting the l2-cache-size parameter for large qcow2 based storage (such as images and ephemeral drives) (see https://events.linuxfoundation.org/sites/events/files/slides/p0.pp_.pdf).

Adding support for this optional parameter (which adds [...]-drive file=hd.qcow2,l2-cache-size=2097152 to the qemu CLI) would allow operators and/or users to configure a more tuned configuration.

A simple implementation where a default value could be set in nova.conf would already give an improved flexibility. A formula could also be used with a factor relative to the size of the storage.

Ideally, this could also be specified as an image or flavor property so that only large drives would need to allocate the additional memory.

I could not locate an option such as this in the OpenStack versions up to Liberty.

Tags: ops
Tom Fifield (fifieldt)
tags: added: ops
Tim Bell (tim-bell)
description: updated
summary: - l2-cache-size support for drives
+ Add support for 'l2-cache-size' (a QCOW2 run time option for metadata
+ cache size) for drives
Revision history for this message
Kashyap Chamarthy (kashyapc) wrote :

Additional info
----------------

The original change in QEMU was introduced in this commit (18 Aug 2014)

    http://git.qemu.org/?p=qemu.git;a=commit;h=6c1c8d5 -- qcow2: Add
    runtime options for cache sizes

And, some documentation on QCOW2 cache configuration:

    http://git.qemu.org/?p=qemu.git;a=blob;f=docs/qcow2-cache.txt;h=5bb0607

Revision history for this message
Mark Doffman (mjdoffma) wrote :

Good summary of the possible performance improvements here:

http://events.linuxfoundation.org/sites/events/files/slides/p0.pp_.pdf

Ofcourse the random read/write tests arn't particularly realistic for actual workloads. The correct value is going to be dependent on the guest workload rather than the cloud operator. Although I agree that the cloud operator could set the cache value to something much higher than 1MB without any downside?

Regardless shouldn't this be made in to a blueprint as its a feature request rather than a bug? Especially since it could be adding new operator configuration options.

Revision history for this message
Augustina Ragwitz (auggy) wrote :

Marked as invalid, this is a feature request.

Changed in nova:
status: New → Invalid
Revision history for this message
Augustina Ragwitz (auggy) wrote :
Revision history for this message
Kashyap Chamarthy (kashyapc) wrote :

[Just to explicitly note here: The bug is marked is "Invalid" only because of a _process_ issue. The actual bug itself is valid.]

The blueprint is filed here:

    https://blueprints.launchpad.net/nova/+spec/qcow2-l2-cache-size-configuration

To post a comment you must log in.
This report contains Public information  
Everyone can see this information.

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.