Re: [libvirt] [PATCH] Add support L2 table cache for qcow2 disk
[...]
> 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