[...] >> 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 -- libvir-list mailing list libvir-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/libvir-list
