[libvirt] [PATCH] Add support L2 table cache for qcow2 disk

[John Ferlan]

[...]

>> 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