Am 25.01.24 um 18:22 schrieb Vladimir Sementsov-Ogievskiy: > > Hmm. Taking maximum is not optimal for usual case without > discard-source: user may want to work in smaller granularity than > source, to save disk space. > > In case with discarding we have two possibilities: > > - either take larger granularity for the whole process like you propose > (but this will need and option for CBW?) > - or, fix discarding bitmap in CBW to work like normal discard: it > should be aligned down. This will lead actually to discard-source option > doing nothing.. > > == > But why do you want fleecing image with larger granularity? Is that a > real case or just experimenting? Still we should fix assertion anyway. >
Yes, it's a real use case. We do support different storage types and want to allow users to place the fleecing image on a different storage than the original image for flexibility. I ran into the issue when backing up to a target with 1 MiB cluster_size while using a fleecing image on RBD (which has 4 MiB cluster_size by default). In theory, I guess I could look into querying the cluster_size of the backup target and trying to allocate the fleecing image with a small enough cluster_size. But not sure if that would work on all storage combinations, and would require teaching our storage plugin API (which also supports third-party plugins) to perform allocation with a specific cluster size. So not an ideal solution for us. > I think: > > 1. fix discarding bitmap to make aligning-down (will do that for v3) > Thanks! > 2. if we need another logic for block_copy_calculate_cluster_size() it > should be an option. May be explicit "copy-cluster-size" or > "granularity" option for CBW driver and for backup job. And we'll just > check that given cluster-size is power of two >= target_size. > I'll try to implement point 2. That should resolve the issue for our use case. Best Regards, Fiona
