From: Fiona Ebner <f.ebner@proxmox.com>
To: pve-devel@lists.proxmox.com
Subject: [pve-devel] [HACK qemu 07/13] block/block-copy: always consider source cluster size too
Date: Thu, 25 Jan 2024 15:41:43 +0100 [thread overview]
Message-ID: <20240125144149.216064-8-f.ebner@proxmox.com> (raw)
In-Reply-To: <20240125144149.216064-1-f.ebner@proxmox.com>
With backup fleecing, it might be necessary to discard the source.
There will be an assertion failure if bitmaps on the source side have
a bigger granularity than the block copy's cluster size, so just
consider the source side too.
This also supersedes the hunk in block/backup.c added by
"PVE-Backup: add backup-dump block driver".
Signed-off-by: Fiona Ebner <f.ebner@proxmox.com>
---
Still need to wait on a response from upstream. For now this hack, so
that the RFC as a whole doesn't have to wait.
block/backup.c | 8 --------
block/block-copy.c | 22 ++++++++++++++--------
2 files changed, 14 insertions(+), 16 deletions(-)
diff --git a/block/backup.c b/block/backup.c
index 51f9d28115..7950bff27e 100644
--- a/block/backup.c
+++ b/block/backup.c
@@ -435,14 +435,6 @@ BlockJob *backup_job_create(const char *job_id, BlockDriverState *bs,
}
cluster_size = block_copy_cluster_size(bcs);
- if (cluster_size < 0) {
- goto error;
- }
-
- BlockDriverInfo bdi;
- if (bdrv_get_info(bs, &bdi) == 0) {
- cluster_size = MAX(cluster_size, bdi.cluster_size);
- }
if (perf->max_chunk && perf->max_chunk < cluster_size) {
error_setg(errp, "Required max-chunk (%" PRIi64 ") is less than backup "
diff --git a/block/block-copy.c b/block/block-copy.c
index 05cfccfda8..cf750ef670 100644
--- a/block/block-copy.c
+++ b/block/block-copy.c
@@ -310,13 +310,19 @@ void block_copy_set_copy_opts(BlockCopyState *s, bool use_copy_range,
}
}
-static int64_t block_copy_calculate_cluster_size(BlockDriverState *target,
+static int64_t block_copy_calculate_cluster_size(BlockDriverState *source,
+ BlockDriverState *target,
Error **errp)
{
int ret;
+ int64_t source_cluster_size = BLOCK_COPY_CLUSTER_SIZE_DEFAULT;
BlockDriverInfo bdi;
bool target_does_cow = bdrv_backing_chain_next(target);
+ if (bdrv_get_info(source, &bdi) == 0) {
+ source_cluster_size = MAX(source_cluster_size, bdi.cluster_size);
+ }
+
/*
* If there is no backing file on the target, we cannot rely on COW if our
* backup cluster size is smaller than the target cluster size. Even for
@@ -327,11 +333,11 @@ static int64_t block_copy_calculate_cluster_size(BlockDriverState *target,
/* Cluster size is not defined */
warn_report("The target block device doesn't provide "
"information about the block size and it doesn't have a "
- "backing file. The default block size of %u bytes is "
+ "backing file. The source's or default block size of %ld bytes is "
"used. If the actual block size of the target exceeds "
- "this default, the backup may be unusable",
- BLOCK_COPY_CLUSTER_SIZE_DEFAULT);
- return BLOCK_COPY_CLUSTER_SIZE_DEFAULT;
+ "this value, the backup may be unusable",
+ source_cluster_size);
+ return source_cluster_size;
} else if (ret < 0 && !target_does_cow) {
error_setg_errno(errp, -ret,
"Couldn't determine the cluster size of the target image, "
@@ -341,10 +347,10 @@ static int64_t block_copy_calculate_cluster_size(BlockDriverState *target,
return ret;
} else if (ret < 0 && target_does_cow) {
/* Not fatal; just trudge on ahead. */
- return BLOCK_COPY_CLUSTER_SIZE_DEFAULT;
+ return source_cluster_size;
}
- return MAX(BLOCK_COPY_CLUSTER_SIZE_DEFAULT, bdi.cluster_size);
+ return MAX(source_cluster_size, bdi.cluster_size);
}
BlockCopyState *block_copy_state_new(BdrvChild *source, BdrvChild *target,
@@ -358,7 +364,7 @@ BlockCopyState *block_copy_state_new(BdrvChild *source, BdrvChild *target,
BdrvDirtyBitmap *copy_bitmap;
bool is_fleecing;
- cluster_size = block_copy_calculate_cluster_size(target->bs, errp);
+ cluster_size = block_copy_calculate_cluster_size(source->bs, target->bs, errp);
if (cluster_size < 0) {
return NULL;
}
--
2.39.2
next prev parent reply other threads:[~2024-01-25 14:41 UTC|newest]
Thread overview: 31+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-01-25 14:41 [pve-devel] [RFC qemu/guest-common/manager/qemu-server/docs 00/13] fix #4136: implement backup fleecing Fiona Ebner
2024-01-25 14:41 ` [pve-devel] [PATCH qemu 01/13] backup: factor out gathering device info into helper Fiona Ebner
2024-01-25 14:41 ` [pve-devel] [PATCH qemu 02/13] backup: get device info: code cleanup Fiona Ebner
2024-01-25 14:41 ` [pve-devel] [PATCH qemu 03/13] block/io: clear BDRV_BLOCK_RECURSE flag after recursing in bdrv_co_block_status Fiona Ebner
2024-01-25 14:41 ` [pve-devel] [RFC qemu 04/13] block/copy-before-write: create block_copy bitmap in filter node Fiona Ebner
2024-01-25 14:41 ` [pve-devel] [RFC qemu 05/13] qapi: blockdev-backup: add discard-source parameter Fiona Ebner
2024-01-25 14:41 ` [pve-devel] [HACK qemu 06/13] block/{copy-before-write, snapshot-access}: implement bdrv_co_get_info driver callback Fiona Ebner
2024-01-29 14:35 ` Fiona Ebner
2024-01-25 14:41 ` Fiona Ebner [this message]
2024-01-25 14:41 ` [pve-devel] [RFC qemu 08/13] PVE backup: add fleecing option Fiona Ebner
2024-01-25 14:41 ` [pve-devel] [RFC guest-common 09/13] vzdump: schema: add fleecing property string Fiona Ebner
2024-01-29 15:41 ` Fiona Ebner
2024-01-30 14:03 ` DERUMIER, Alexandre
2024-02-01 8:28 ` Fiona Ebner
2024-02-01 12:39 ` DERUMIER, Alexandre
2024-02-01 13:11 ` Fiona Ebner
2024-02-01 13:20 ` DERUMIER, Alexandre
2024-02-01 13:27 ` Fiona Ebner
2024-02-01 21:33 ` DERUMIER, Alexandre
2024-02-02 8:30 ` Fiona Ebner
2024-02-01 13:30 ` Fiona Ebner
2024-01-25 14:41 ` [pve-devel] [RFC manager 10/13] vzdump: handle new 'fleecing' " Fiona Ebner
2024-01-25 14:41 ` [pve-devel] [RFC qemu-server 11/13] backup: disk info: also keep track of size Fiona Ebner
2024-01-25 14:41 ` [pve-devel] [RFC qemu-server 12/13] backup: implement fleecing option Fiona Ebner
2024-01-29 15:28 ` Fiona Ebner
2024-01-25 14:41 ` [pve-devel] [RFC docs 13/13] vzdump: add section about backup fleecing Fiona Ebner
2024-01-25 16:13 ` Dietmar Maurer
2024-01-25 16:41 ` DERUMIER, Alexandre
2024-01-25 18:18 ` Dietmar Maurer
2024-01-26 8:39 ` Fiona Ebner
2024-01-25 16:02 ` [pve-devel] [RFC qemu/guest-common/manager/qemu-server/docs 00/13] fix #4136: implement " DERUMIER, Alexandre
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20240125144149.216064-8-f.ebner@proxmox.com \
--to=f.ebner@proxmox.com \
--cc=pve-devel@lists.proxmox.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.