Re: [Qemu-devel] [PATCH v3 13/18] block: introduce new filter driver: fleecing-hook

[Vladimir Sementsov-Ogievskiy]

04.10.2018 15:44, Kevin Wolf wrote:
> Am 01.10.2018 um 12:29 hat Vladimir Sementsov-Ogievskiy geschrieben:
>> Fleecing-hook filter does copy-before-write operation. It should be
>> inserted above active disk and has a target node for CBW, like the
>> following:
>>
>>      +-------+
>>      | Guest |
>>      +---+---+
>>          |r,w
>>          v
>>      +---+-----------+  target   +---------------+
>>      | Fleecing hook |---------->| target(qcow2) |
>>      +---+-----------+   CBW     +---+-----------+
>>          |                           |
>> backing |r,w                        |
>>          v                           |
>>      +---+---------+      backing    |
>>      | Active disk |<----------------+
>>      +-------------+        r
>>
>> Target's backing may point to active disk (should be set up
>> separately), which gives fleecing-scheme.
>>
>> Signed-off-by: Vladimir Sementsov-Ogievskiy <address@hidden>
> This lacks an explanation why we need a specialised fleecing hook driver
> rather than just a generic bdrv_backup_top block driver in analogy to
> what commit and mirror are already doing.
>
> In fact, if I'm reading the last patch of the series right, backup
> doesn't even restrict the use of the fleecing-hook driver to actual
> fleecing scenarios.
>
> Maybe what doesn't feel right to me is just that it's a misnomer, and if
> you rename it into bdrv_backup_top (and make it internal to the block
> job), it is very close to what I actually have in mind?
>
> Kevin

Hm.
1. assume we move to internal bdrv_backup_top
2. backup(mode=none) becomes just a wrapper for append/drop of the 
bdrv_backup_top node
3. looks interesting to get rid of empty (doing nothing) job and use 
bdrv_backup_top directly.

I want to finally create different backup schemes, based on fleecing 
hook, for example:

     +-------+
     | Guest |
     +-------+
         |r,w
         v
     +---+-----------+  target   +---------------+ +--------+
     | Fleecing hook +---------->+ fleecing-node +---------->+ target |
     +---+-----------+   CBW     +---+-----------+ backup +--------+
         |                           |             (no hook)
backing |r,w                        |
         v                           |
     +---+---------+      backing    |
     | Active disk +<----------------+
     +-------------+        r


This is needed for slow nbd target, if we don't need to slow down guest 
writes.
Here backup(no hook) is a backup job without hook / write notifiers, as 
it actually
do copy from static source.

Or, we can use mirror instead of backup, as mirror is asynchronous and 
is faster than backup. We can even use mirror with write-blocking mode 
(proposed by Max) and use something like null bds (but with backing) 
instead of qcow2 fleecing-node - this will imitate current backup 
approach, but with mirror instead of backup.

Of course, we can use old backup(sync=none) for all such schemes, I just 
think that architecture with filter node is more clean, than with backup 
job, which looks the same but with additional job:
     +-------+
     | Guest |
     +-------+
         |r,w
         v
     +---------------+  target   +---------------+ +--------+
     |bdrv_backup_top+---------->+ fleecing-node +---------->+ target |
     +---------------+   CBW     +---+----------++ backup +--------+
         |                           |          ^  (no hook)
backing |r,w                        |          |
         v                           |          |
     +---+---------+      backing    |          |
     | Active disk +<----------------+          |
     +----------+--+        r                   |
                |                               |
                |           backup(sync=none)   |
                +-------------------------------+



Finally, the first picture looks nicer and has less entities (and I 
didn't draw target blk which backup creates and all the permissions). 
Hmm, it also may be more difficult to setup permissions in the second 
scheme, but I didn't dive into. We just agreed with Max that separate 
building brick which may be reused in different schemes is better than 
internal thing in backup, so, I went this way. However, if you are 
against, it isn't difficult to move it all into backup.

-- 
Best regards,
Vladimir