Re: [libvirt] [PATCH v4 1/2] conf, docs: Add qcow2 cache configuration support
On Thu, Sep 14, 2017 at 09:29:28AM +0200, Peter Krempa wrote:
On Thu, Sep 14, 2017 at 13:02:46 +0800, Liu Qing wrote:
> On Wed, Sep 13, 2017 at 01:20:03PM +0200, Peter Krempa wrote:
> > On Wed, Sep 13, 2017 at 17:21:23 +0800, Liu Qing wrote:
[...]
> > [1] There's discussion I can link to for other tuning parameters. The
> > gist is that allowing users to set something withoug giving them
> > guidance is pointless since they might not use it. Also if the guidance
> > is strict (e.g. a formula, libvirt or qemu should set the defaults
> > properly and not force users to do the calculation)
> The guidance could be found in doc/qcow2-cache.txt in qemu source code.
> As John Ferlan suggested I have added the file locaton in formatdomain.html.in.
Well, if the guidance is absolute (use this cache size and it's okay)
then we should implement it automatically (don't allow users
to set it.)
I'm asking whether there are some catches why not to do it automatically.
E.g whether there's an possibility that users would do something *else*
as described by the document and what would be the reasons for it.
I think there is
some trade off between the cache size and performance.
Otherwise qemu does not need to export these parameters to user, they
could do the automation in qemu. The guidance only let the user know how
much disk space is coverred by caches, and how much memory will be
needed to cover all disk spaces. User should do their own decision to
choose a right size. But if the user is using the current version of
libvirt, they could not set the value even if they know what's the
proper value.
For example if the user may need a LUN which need high IOPS, he could
set the cache to cover all disk spaces. And in another situation, he
needs a large capacity,for example 4T, but low perfermance LUN, then he
could set the l2 cache size to a value much less than 512M.
One of the reasons might be memory consumption of the cache as it
looks like you need 1 MiB of memory to fully cover a 8GiB image.
Yes, as I said
above.
Also the problem is that those parameters are qemu-isms so we should be
aware when modelling them in the XML since they can change and may not
map well to any other technology.
Currently the new element is added as a child
elemnt of driver, and the
driver type needs to be qcow2. Also add this kind information in the
doc.
Also how does the cache impact read-performance from the backing layers?
We might need to set the cache for the backing layers as well.
I have a peek at the
latest qemu code and the backing layers will have
the same cache size value as the top volume. And this will reduce metadata read
count if the table is already in the memory. Also more memory will
consumed.