Am 19.05.2021 um 13:49 hat Vladimir Sementsov-Ogievskiy geschrieben: > 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 Yes, that's an option, too. Kevin
