30.07.2019 21:22, John Snow wrote: > > > On 7/30/19 12:32 PM, Vladimir Sementsov-Ogievskiy wrote: >> Enabled by default copy_range ignores compress option. It's definitely >> unexpected for user. >> >> It's broken since introduction of copy_range usage in backup in >> 9ded4a011496. >> >> Signed-off-by: Vladimir Sementsov-Ogievskiy <vsement...@virtuozzo.com> >> --- >> block/backup.c | 2 +- >> 1 file changed, 1 insertion(+), 1 deletion(-) >> >> diff --git a/block/backup.c b/block/backup.c >> index f4aaf08df3..c5f941101a 100644 >> --- a/block/backup.c >> +++ b/block/backup.c >> @@ -645,7 +645,7 @@ BlockJob *backup_job_create(const char *job_id, >> BlockDriverState *bs, >> job->cluster_size = cluster_size; >> job->copy_bitmap = copy_bitmap; >> copy_bitmap = NULL; >> - job->use_copy_range = true; >> + job->use_copy_range = !compress; /* compression isn't supported for it >> */ >> job->copy_range_size = >> MIN_NON_ZERO(blk_get_max_transfer(job->common.blk), >> blk_get_max_transfer(job->target)); >> job->copy_range_size = MAX(job->cluster_size, >> > > Agree, these aren't compatible options. Is this worth a note in > docs/interop/live-block-operations.rst?
Use_copy_range is not an user-visible option and it's not documented as I can see, so I think we don't need. > > Reviewed-by: John Snow <js...@redhat.com> > -- Best regards, Vladimir
