[libvirt] [PATCH] Add support L2 table cache for qcow2 disk
John Ferlan
jferlan at redhat.com
Fri Jun 29 11:10:23 UTC 2018
[...]
>> 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
More information about the libvir-list
mailing list