Re: [Qemu-devel] [PATCH 0/2] buffer and delay backup COW write operation

[Liang Li <liliang.opensource@gmail.com>]

On Tue, Apr 30, 2019 at 10:35:32AM +0000, Vladimir Sementsov-Ogievskiy wrote:
> 28.04.2019 13:01, Liang Li wrote:
> > If the backup target is a slow device like ceph rbd, the backup
> > process will affect guest BLK write IO performance seriously,
> > it's cause by the drawback of COW mechanism, if guest overwrite the
> > backup BLK area, the IO can only be processed after the data has
> > been written to backup target.
> > The impact can be relieved by buffering data read from backup
> > source and writing to backup target later, so the guest BLK write
> > IO can be processed in time.
> > Data area with no overwrite will be process like before without
> > buffering, in most case, we don't need a very large buffer.
> > 
> > An fio test was done when the backup was going on, the test resut
> > show a obvious performance improvement by buffering.
> 
> Hi Liang!
> 
> Good thing. Something like this I've briefly mentioned in my KVM Forum 2018
> report as "RAM Cache", and I'd really prefer this functionality to be a separate
> filter, instead of complication of backup code. Further more, write notifiers
> will go away from backup code, after my backup-top series merged.
> 
> v5: https://lists.gnu.org/archive/html/qemu-devel/2018-12/msg06211.html
> and separated preparing refactoring v7: https://lists.gnu.org/archive/html/qemu-devel/2019-04/msg04813.html
> 
> RAM Cache should be a filter driver, with an in-memory buffer(s) for data written to it
> and with ability to flush data to underlying backing file.
> 
> Also, here is another approach for the problem, which helps if guest writing activity
> is really high and long and buffer will be filled and performance will decrease anyway:
> 
> 1. Create local temporary image, and COWs will go to it. (previously considered on list, that we should call
> these backup operations issued by guest writes CBW = copy-before-write, as copy-on-write
> is generally another thing, and using this term in backup is confusing).
> 
> 2. We also set original disk as a backing for temporary image, and start another backup from
> temporary to real target.
> 
> This scheme is almost possible now, you need to start backup(sync=none) from source to temp,
> to do [1]. Some patches are still needed to allow such scheme. I didn't send them, as I want
> my other backup patches go first anyway. But I can. On the other hand if approach with in-memory
> buffer works for you it may be better.
> 
> Also, I'm not sure for now, should we really do this thing through two backup jobs, or we just
> need one separate backup-top filter and one backup job without filter, or we need an additional
> parameter for backup job to set cache-block-node.
> 

Hi Vladimir,

   Thanks for your valuable information. I didn't notice that you are already working on
this,  so my patch will conflict with your work. We have thought about the way [2] and
give it up because it would affect local storage performance.
   I have read your slice in KVM Forum 2018 and the related patches, your solution can
help to solve the issues in backup. I am not sure if the "RAM cache" is a qcow2 file in
RAM? if so, your implementation will free the RAM space occupied by BLK data once it's
written to the far target in time? or we may need a large cache to make things work.
   Two backup jobs seems complex and not user friendly, is it possible to make my patch
cowork with CBW?

Liang