Re: [libvirt] [PATCH v5 1/2] conf, docs: Add qcow2 cache configuration support

On 09/14/2017 01:08 AM, Liu Qing wrote: > Random write IOPS will drop dramatically if qcow2 l2 cache could not > cover the whole disk. This patch gives libvirt user a chance to adjust > the qcow2 cache configuration. > > Three new qcow2 driver parameters (l2-cache-size, refcount-cache-size > and cache-clean-interval) are added as attributes to a new <qcow2> > subelement for a <driver name='qemu' type='qcow2'...> of a <disk> > element. The QEMU source docs/qcow2-cache.txt provides the guidelines > for defining/configuring values for each. > > Signed-off-by: Liu Qing <liuqing(a)huayun.com&gt; > --- > docs/formatdomain.html.in | 41 +++++++++ > docs/schemas/domaincommon.rng | 35 ++++++++ > src/conf/domain_conf.c | 96 ++++++++++++++++++++-- > src/qemu/qemu_driver.c | 5 ++ > src/util/virstoragefile.c | 3 + > src/util/virstoragefile.h | 6 ++ > .../qemuxml2argv-disk-drive-qcow2-cache.xml | 43 ++++++++++ > .../qemuxml2xmlout-disk-drive-qcow2-cache.xml | 43 ++++++++++ > tests/qemuxml2xmltest.c | 1 + > 9 files changed, 268 insertions(+), 5 deletions(-) > create mode 100644 tests/qemuxml2argvdata/qemuxml2argv-disk-drive-qcow2-cache.xml > create mode 100644 tests/qemuxml2xmloutdata/qemuxml2xmlout-disk-drive-qcow2-cache.xml > OK - so I had my head in other code during the v4 review comments from Peter. So I'll just "restart" that a bit here. If I can summarize the comments... There's a concern that we're creating a very specific set of parameters for which there isn't great guidance available other than going to a source file in the qemu tree and attempting to decipher it. Something I did note at one time as a possible issue and why I also asked for the "qcow2" subelement. It makes it painfully obvious that there was something very specific. I figure seeing a "qcow2" element name would fairly easily point out to anyone that specificity. So, based on what I read in the responses it seems that the purpose of the values is to provide a mechanism to "allow" qemu to use a couple of different algorithms to perform operations, but qemu wants the user to decide whether they are willing to sacrifice one thing over another. If you want high IOPS, then you have to sacrifice something else; whereas, if you don't care about performance, then you sacrifice something else. In any case, I think what could be useful is to determine if there is a way to "automate" something such that the "dials" would be automatically set based on the algorithms. That is - rather than supplying the specific values, supply a named attribute that would then perform the calculations and set the values, such as "high_performance="yes" or "large_capacity=yes". Where you cannot set both, but can set one or the other. Or can you set both? Is there value in partially turning a knob? If so maybe the attribute is "performance={default, ..., best}" and "capacity={default, ..., large}". Then based on the value of the attribute, code you add to libvirt would perform the calculations. Or do you really think that's something some supplier (such as what you're trying to do) would want to have - the ability to control the algorithm for the various knobs.