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 <vsement...@virtuozzo.com> > 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
