[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Qemu-block] [PATCH for-2.12 v2] qcow2: Reset free_cluster_index whe

From: Kevin Wolf
Subject: Re: [Qemu-block] [PATCH for-2.12 v2] qcow2: Reset free_cluster_index when allocating a new refcount block
Date: Wed, 21 Mar 2018 14:52:38 +0100
User-agent: Mutt/1.9.1 (2017-09-22)

Am 21.03.2018 um 14:38 hat Alberto Garcia geschrieben:
> This can be reproduced easily:
>      qemu-img create -f qcow2 -o cluster_size=512 hd.qcow2 1M
>      qemu-io -c 'write 0 124k' hd.qcow2
> After this the image has 132608 bytes (256 clusters), and the refcount
> block is full. If we write 512 more bytes it should allocate two new
> clusters: the data cluster itself and a new refcount block.
>      qemu-io -c 'write 124k 512' hd.qcow2
> However the image has now three new clusters (259 in total), and the
> first one of them is empty (and unallocated):
>      dd if=hd.qcow2 bs=512c skip=256 count=1 | hexdump -C
> If we write larger amounts of data in the last step instead of the 512
> bytes used in this example we can create larger holes in the qcow2
> file.

So if I understand correctly, this is what we get:

0x20000: free
0x20200: refcount block
0x20400: data cluster
0x20600: potential next data cluster

> What this patch does is reset s->free_cluster_index to its previous
> value when alloc_refcount_block() returns -EAGAIN. This way the caller
> will try to allocate again the original clusters if they are still
> free.

This is an improvement, because now we should avoid the unused cluster:

0x20000: data cluster
0x20200: refcount block
0x20400: potential next data cluster

But now the data clusters are fragmented. Should we try to change the
logic so that already the refcount block allocation can make use of the
free space? That is:

0x20000: refcount block
0x20200: data cluster
0x20400: contiguous potential next data cluster


reply via email to

[Prev in Thread] Current Thread [Next in Thread]