On Mon 27 Apr 2020 09:49:00 AM CEST, Max Reitz wrote:
>> The point is this: Consider 'write -P 0xff 0 64k', then 'write -z 16k
>> 16k', then 'read 0 64k'. For normal clusters, we can just do a
>> scatter-gather iov read of read 0-16k and 32-64k, plus a memset of
>> 16-32k. But for compressed
On 24.04.20 20:47, Eric Blake wrote:
> On 4/24/20 1:37 PM, Alberto Garcia wrote:
>> On Fri 24 Apr 2020 08:25:45 PM CEST, Vladimir Sementsov-Ogievskiy
>> wrote:
> Reading the entire cluster will be interesting - you'll have to
> decompress the entire memory, then overwrite the zeroed
24.04.2020 21:41, Alberto Garcia wrote:
On Fri 24 Apr 2020 08:15:04 PM CEST, Vladimir Sementsov-Ogievskiy
wrote:
AFAIK, now compressed clusters can't be used in scenarios with guest,
as qcow2 driver doesn't support rewriting them.
You can write to those images just fine, it's just not
On 4/24/20 1:37 PM, Alberto Garcia wrote:
On Fri 24 Apr 2020 08:25:45 PM CEST, Vladimir Sementsov-Ogievskiy
wrote:
Reading the entire cluster will be interesting - you'll have to
decompress the entire memory, then overwrite the zeroed portions.
I don't think so, qcow2_get_host_offset()
On Fri 24 Apr 2020 08:15:04 PM CEST, Vladimir Sementsov-Ogievskiy
wrote:
> AFAIK, now compressed clusters can't be used in scenarios with guest,
> as qcow2 driver doesn't support rewriting them.
You can write to those images just fine, it's just not efficient because
you have to COW the
On Fri 24 Apr 2020 08:25:45 PM CEST, Vladimir Sementsov-Ogievskiy
wrote:
>>> Reading the entire cluster will be interesting - you'll have to
>>> decompress the entire memory, then overwrite the zeroed portions.
>>
>> I don't think so, qcow2_get_host_offset() would detect the number of
>>
24.04.2020 20:56, Alberto Garcia wrote:
On Fri 24 Apr 2020 07:44:33 PM CEST, Eric Blake wrote:
at the same time, I can see where you're coming from in stating that
if it makes management of extended L2 easier to allow zero subclusters
on top of a compressed cluster, then there's no reason to
24.04.2020 20:44, Eric Blake wrote:
On 4/24/20 12:21 PM, Alberto Garcia wrote:
On Fri 24 Apr 2020 07:11:08 PM CEST, Eric Blake wrote:
'write -c 0 64k' followed by 'write -z 16k 16k' would not need to do any
copy on write. The compressed data would remain untouched on disk but
some of the
On Fri 24 Apr 2020 07:44:33 PM CEST, Eric Blake wrote:
>>> at the same time, I can see where you're coming from in stating that
>>> if it makes management of extended L2 easier to allow zero subclusters
>>> on top of a compressed cluster, then there's no reason to forbid it.
>>
>> I'm not sure
On 4/24/20 12:21 PM, Alberto Garcia wrote:
On Fri 24 Apr 2020 07:11:08 PM CEST, Eric Blake wrote:
'write -c 0 64k' followed by 'write -z 16k 16k' would not need to do any
copy on write. The compressed data would remain untouched on disk but
some of the subclusters would have the 'all zeroes'
On Fri 24 Apr 2020 07:11:08 PM CEST, Eric Blake wrote:
>> 'write -c 0 64k' followed by 'write -z 16k 16k' would not need to do any
>> copy on write. The compressed data would remain untouched on disk but
>> some of the subclusters would have the 'all zeroes' bit set, exactly
>> like what happens
On 4/24/20 12:02 PM, Alberto Garcia wrote:
On Tue 17 Mar 2020 07:16:21 PM CET, Alberto Garcia wrote:
Compressed clusters always have the bitmap part of the extended L2
entry set to 0.
I was just finishing some improvements to the new code that allows
BDRV_REQ_ZERO_WRITE at the subcluster
On Tue 17 Mar 2020 07:16:21 PM CET, Alberto Garcia wrote:
> Compressed clusters always have the bitmap part of the extended L2
> entry set to 0.
I was just finishing some improvements to the new code that allows
BDRV_REQ_ZERO_WRITE at the subcluster level, and I'm starting to
entertain the idea
Compressed clusters always have the bitmap part of the extended L2
entry set to 0.
Signed-off-by: Alberto Garcia
Reviewed-by: Max Reitz
---
block/qcow2-cluster.c | 3 +++
1 file changed, 3 insertions(+)
diff --git a/block/qcow2-cluster.c b/block/qcow2-cluster.c
index dfd8b66958..1f471db98c
14 matches
Mail list logo
