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.
Kevin
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
--
Best regards,
Vladimir