Re: backup_calculate_cluster_size does not consider source

[Dietmar Maurer]

> On 6 November 2019 14:17 Max Reitz <address@hidden> wrote:
> 
>  
> On 06.11.19 14:09, Dietmar Maurer wrote:
> >> Let me elaborate: Yes, a cluster size generally means that it is most
> >> “efficient” to access the storage at that size.  But there’s a tradeoff.
> >>  At some point, reading the data takes sufficiently long that reading a
> >> bit of metadata doesn’t matter anymore (usually, that is).
> > 
> > Any network storage suffers from long network latencies, so it always
> > matters if you do more IOs than necessary.
> 
> Yes, exactly, that’s why I’m saying it makes sense to me to increase the
> buffer size from the measly 64 kB that we currently have.  I just don’t
> see the point of increasing it exactly to the source cluster size.
> 
> >> There is a bit of a problem with making the backup copy size rather
> >> large, and that is the fact that backup’s copy-before-write causes guest
> >> writes to stall. So if the guest just writes a bit of data, a 4 MB
> >> buffer size may mean that in the background it will have to wait for 4
> >> MB of data to be copied.[1]
> > 
> > We use this for several years now in production, and it is not a problem.
> > (Ceph storage is mostly on 10G (or faster) network equipment).
> 
> So you mean for cases where backup already chooses a 4 MB buffer size
> because the target has that cluster size?

To make it clear. Backups from Ceph as source are slow.

That is why we use a patched qemu version, which uses:

cluster_size = Max_Block_Size(source, target)

(I guess this only triggers for ceph)