Re: RFC: Qemu backup interface plans - Vladimir Sementsov-Ogievskiy

From: Vladimir Sementsov-Ogievskiy <vsementsov@virtuozzo.com>
To: Kevin Wolf <kwolf@redhat.com>
Cc: Max Reitz <mreitz@redhat.com>,
	qemu-block@nongnu.org, qemu-devel <qemu-devel@nongnu.org>,
	Eric Blake <eblake@redhat.com>, John Snow <jsnow@redhat.com>,
	"Denis V. Lunev" <den@openvz.org>,
	Nikolay Shirokovskiy <nshirokovskiy@virtuozzo.com>,
	Dmitry Mishin <dim@virtuozzo.com>,
	Igor Sukhih <igor@virtuozzo.com>,
	yur@virtuozzo.com, Peter Krempa <pkrempa@redhat.com>,
	"libvir-list@redhat.com" <libvir-list@redhat.com>
Subject: Re: RFC: Qemu backup interface plans
Date: Wed, 19 May 2021 14:49:24 +0300	[thread overview]
Message-ID: <b519b530-f268-59af-145e-6370004bdbdd@virtuozzo.com> (raw)
In-Reply-To: <YKT0Z8aCZiCpcysd@merkur.fritz.box>

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