[...]
Well, from my example, what units are "128" and "8" in? Also, in libvirt we give users possibility to specify other units than KiB (even though we report back size in KiB), for instance look at <memory/> numa <cell/>. Also, your proposal is not that future proof. My suggestion is:
<cache> <cache level='2'> <size unit='KiB'>128</size> </cache> <clean interval='8'/> </cache>
But I'm sure there's even better approach.
There were at least two attempts to implement this in the past which we've rejected as the configuration of this is more of a black magic than anything which users could do and there was no solid documentation how to tackle it or make it useful for higher level management apps.
There's some updated description in the qemu.git/docs/qcow2-cache.txt and in the last few months Berto has made changes to upstream qemu in this area, see: http://lists.nongnu.org/archive/html/qemu-devel/2018-04/msg02406.html which ends through commit id 52253998 http://lists.nongnu.org/archive/html/qemu-devel/2018-02/msg00911.html which ends through as commit id 03b1b6f02. IIRC this one provided even more knobs to turn, but if you follow the links back to the v2 and v1 patches - each has a decent cover letter summarizing the state of things at the qemu level at least.
IIRC John provided a link to the latest discussion which also had patches. Those were much more complete and documented than this and had better naming of those.
Yep, I believe this is the same author as earlier this week: https://www.redhat.com/archives/libvir-list/2018-June/msg01721.html Berto even dropped some details on libvir-list during the review of the proposed Nov 2017 changes by Lin Ma, see: https://www.redhat.com/archives/libvir-list/2017-November/msg00572.html
It may be worth reopening the discussion whether to include this but I'd certainly go with one of the older versions.
For as many times as we see this particular area - it feels that way. Anyone know a good patch necromancer ;-). If we do take that option, then we may also need to reconsider the poll-max-ns for IOThreads (see https://bugzilla.redhat.com/show_bug.cgi?id=1545732) which points one at Pavel's series: https://www.redhat.com/archives/libvir-list/2017-February/msg01047.html John