Re: [Libguestfs] Some questions about nbdkit vs qemu performance affecting virt-v2v
On Tue, Jul 27, 2021 at 01:28:17PM +0100, Richard W.M. Jones wrote:
> >Q2: Should we consider a "cow-on-read" flag to the
cow filter (thus
> >removing the need to use the cache filter at all)?
> >
>
> That would make at least some sense since there is cow-on-cache already
> (albeit a little confusing for me personally).
I forgot about that one. cow-on-read would work similarly.
> I presume it would not increase the size of the difference (when
> using qemu-img rebase) at all, right? I do not see however how it
> would be faster than the existing:
>
> cow <- cache[cache-on-read]
It should be simpler. I'm also worried that I'm missing something and
that maybe cow + cache + cache-on-read is actually double-caching in
some case that I didn't think of.
Using both cow and cache filters (especially with cache-on-read in the
cache filter) will indeed cache some portions of the disk twice, both
in the cache filter (when it is first read), then again in the cow
filter (after it is first written). But once that portion of the disk
lives in the cow local file, we'll never access that portion of the
temp file from the cache filter again. I don't know that you'll lose
much performance, but it can use more disk space and/or memory than
necessary, particularly if the cow filter alone is sufficient to do
cache-on-read (for some reason, the term cow-on-read sounds odd to me,
since it expands to copy-on-write-on-read).
--
Eric Blake, Principal Software Engineer
Red Hat, Inc. +1-919-301-3266
Virtualization: qemu.org | libvirt.org