Re: RFC: Qemu backup interface plans

19.05.2021 14:20, Kevin Wolf wrote: > Am 19.05.2021 um 08:11 hat Vladimir Sementsov-Ogievskiy geschrieben: > > > > 2. Test, that we can start backup job with source = (target of > > > > backup-top filter), so that we have "push backup with fleecing". > > > > Make an option for backup to start without a filter, when we don't > > > > need copy-before-write operations, to not create extra superfluous > > > > filter. > > > > > > OK, so the backup job is not really a backup job, but just anything > > > that copies data. > > > > Not quite. For backup without a filter we should protect source from > > changing, by unsharing WRITE permission on it. > > > > I'll try to avoid adding an option. The logic should work like in > > commit job: if there are current writers on source we create filter. > > If there no writers, we just unshare writes and go without a filter. > > And for this copy-before-write filter should be able to do > > WRITE_UNCHANGED in case of fleecing. > > If we ever get to the point where we would make a block-copy job visible > to the user, I wouldn't copy the restrictions from the current jobs, but > keep it really generic to cover all cases. > > There is no way for the QMP command starting the job to know what the > user is planning to do with the image in the future. Even if it's > currently read-only, the user may want to add a writer later. > > I think this means that we want to always add a filter node, and then > possibly dynamically switch between modes if being read-only provides a > significant advantage for the job. Still, in push-backup-with-fleecing scheme we really don't need the second filter, so why to insert extra thing to block graph? I see your point still, that user may want to add writer later. Still, I'd be surprised if such use-cases exist now. What about the following: add some source-mode tri-state parameter for backup: auto: insert filter iff there are existing writers [default] filtered: insert filter unconditionally immutable: don't insert filter. will fail if there are existing writers, and creating writers during block-job would be impossible