On 16.02.22 20:46, Vladimir Sementsov-Ogievskiy wrote:
We are on the way to implement internal-backup with fleecing scheme,
which includes backup job copying from fleecing block driver node
(which is target of copy-before-write filter) to final target of
backup. This job doesn't need own filter, as fleecing block driver node
is a kind of snapshot, it's immutable from reader point of view.
Let's add a parameter for backup to not insert filter but instead
unshare writes on source. This way backup job becomes a simple copying
process.
Signed-off-by: Vladimir Sementsov-Ogievskiy <vsement...@virtuozzo.com>
---
qapi/block-core.json | 11 ++++++-
include/block/block_int.h | 1 +
block/backup.c | 61 +++++++++++++++++++++++++++++++++++----
block/replication.c | 2 +-
blockdev.c | 1 +
5 files changed, 69 insertions(+), 7 deletions(-)
I’m not really technically opposed to this, but I wonder what the actual
benefit of this is. It sounds like the only benefit is that we don’t
need a filter driver, but what’s the problem with such a filter driver?
(And if we just want to copy data off of a immutable node, I personally
would go for the mirror job instead, but it isn’t like I could give good
technical reasons for that personal bias.)
