Re: [PATCH v3 6/6] block/qcow2: use seqcache for compressed writes

[Max Reitz <mreitz@redhat.com>]

On 16.03.21 18:48, Vladimir Sementsov-Ogievskiy wrote:
> 16.03.2021 15:25, Max Reitz wrote:
>> On 15.03.21 15:40, Vladimir Sementsov-Ogievskiy wrote:
>>> 15.03.2021 12:58, Max Reitz wrote:
>>
>> [...]
>>
>>>> The question is whether it really makes sense to even have a 
>>>> seqcache_read() path when in reality it’s probably never accessed.  
>>>> I mean, besides the fact that it seems based purely on chance 
>>>> whether a read might fetch something from the cache even while we’re 
>>>> writing, in practice I don’t know any case where we’d write to and 
>>>> read from a compressed qcow2 image at the same time.  (I don’t know 
>>>> what you’re doing with the 'compress' filter, though.)
>>>>
>>>
>>> Note, that for user that's not a parallel write and read to the same 
>>> cluster:
>>>
>>> 1. user writes cluster A, request succeeded, data is in the cache
>>>
>>> 2. user writes some other clusters, cache filled, flush started
>>>
>>> 3. in parallel to [2] user reads cluster A. From the POV of user, 
>>> cluster A is written already, and should be read successfully
>>
>> Yes, but when would that happen?
>>
>>> And seqcache_read() gives a simple non-blocking way to support read 
>>> operation.
>>
>> OK, that makes sense.  We’d need to flush the cache before we can read 
>> anything from the disk, so we should have a read-from-cache branch here.
>>
>>> But rewriting compressed clusters is sensible only when we run real 
>>> guest on compressed image.. Can it be helpful? Maybe for scenarios 
>>> with low disk usage ratio..
>>
>> I’m not sure, but the point is that rewrites are currently not 
>> supported.  The whole compression implementation is mainly tailored 
>> towards just writing a complete image (e.g. by qemu-img convert or the 
>> backup job), so that’s where my question is coming from: It’s 
>> difficult for me to see a currently working use case where you’d read 
>> from and write to a compressed image at the same time.
>>
> 
> External backup works like the following:
> 
>   - start backup sync=none from active disk to temporary disk
>   - export temporary disk through nbd
>   - external tool reads from nbd export
> 
> For this scheme it may make sense to use compression,

Not sure whether it really does, because it’s my impression the 
temporary disk is deleted after the backup, but no matter: You’re right, 
that’s indeed a valid case.

Max