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.
Kevin