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 _______________________________________________ Libguestfs mailing list [email protected] https://listman.redhat.com/mailman/listinfo/libguestfs
