On 28.06.20 13:02, Alberto Garcia wrote: > If an image has subclusters then there are more copy-on-write > scenarios that we need to consider. Let's say we have a write request > from the middle of subcluster #3 until the end of the cluster: > > 1) If we are writing to a newly allocated cluster then we need > copy-on-write. The previous contents of subclusters #0 to #3 must > be copied to the new cluster. We can optimize this process by > skipping all leading unallocated or zero subclusters (the status of > those skipped subclusters will be reflected in the new L2 bitmap). > > 2) If we are overwriting an existing cluster: > > 2.1) If subcluster #3 is unallocated or has the all-zeroes bit set > then we need copy-on-write (on subcluster #3 only). > > 2.2) If subcluster #3 was already allocated then there is no need > for any copy-on-write. However we still need to update the L2 > bitmap to reflect possible changes in the allocation status of > subclusters #4 to #31. Because of this, this function checks > if all the overwritten subclusters are already allocated and > in this case it returns without creating a new QCowL2Meta > structure. > > After all these changes l2meta_cow_start() and l2meta_cow_end() > are not necessarily cluster-aligned anymore. We need to update the > calculation of old_start and old_end in handle_dependencies() to > guarantee that no two requests try to write on the same cluster. > > Signed-off-by: Alberto Garcia <be...@igalia.com> > Reviewed-by: Eric Blake <ebl...@redhat.com> > --- > block/qcow2-cluster.c | 163 +++++++++++++++++++++++++++++++++--------- > 1 file changed, 131 insertions(+), 32 deletions(-)
Reviewed-by: Max Reitz <mre...@redhat.com>
signature.asc
Description: OpenPGP digital signature