Re: [Qemu-devel] [PATCH 02/10] qcow2: add qcow2_co_write_compressed

[Eric Blake <eblake@redhat.com>]

[-- Attachment #1: Type: text/plain, Size: 1747 bytes --]

On 05/31/2016 03:00 PM, Denis V. Lunev wrote:
> On 05/31/2016 09:42 PM, Eric Blake wrote:
>> On 05/30/2016 06:58 AM, Pavel Butsykin wrote:
>>
>>> Sorry, but it seems this will never happen, because the second write
>>> will not pass this check:
>>>
>>> uint64_t qcow2_alloc_compressed_cluster_offset(BlockDriverState *bs,
>>>                                                 uint64_t offset,
>>>                                                 int compressed_size)
>>> {
>>>      ...
>>>      /* Compression can't overwrite anything. Fail if the cluster was
>>> already
>>>       * allocated. */
>>>      cluster_offset = be64_to_cpu(l2_table[l2_index]);
>>>      if (cluster_offset & L2E_OFFSET_MASK) {
>>>          qcow2_cache_put(bs, s->l2_table_cache, (void**) &l2_table);
>>>          return 0;
>>>      }
>>>     ...
>>>
>>> As you can see we can't do the compressed write in the already allocated
>>> cluster.
>> Umm, doesn't that defeat the point of compression, if every compressed
>> cluster becomes the head of a new cluster?  The whole goal of
>> compression is to be able to fit multiple clusters within one.
>>
> AFAIK the file will be sparse in that unused areas

IIRC, on the NTFS file system, the minimum hole size is 64k. If you also
have 64k clusters, then you don't have a sparse file - every tail of
zero sectors will be explicit in the filesystem, if you are using 1:1
clusters for compression.  Other file systems may have finer granularity
for holes, but it's still rather awkward to be relying on sparseness
when a better solution is to pack compressed sectors consecutively.

-- 
Eric Blake   eblake redhat com    +1-919-301-3266
Libvirt virtualization library http://libvirt.org


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 604 bytes --]