RFC: Qemu backup interface plans

[Vladimir Sementsov-Ogievskiy]

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