qemu-devel
[Top][All Lists]
Advanced

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

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


From: Vladimir Sementsov-Ogievskiy
Subject: Re: [PATCH v3 6/6] block/qcow2: use seqcache for compressed writes
Date: Tue, 16 Mar 2021 20:48:41 +0300
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:78.0) Gecko/20100101 Thunderbird/78.8.1

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, and we get a use case 
where compressed reads and writes are used in the same time. Moreover this is 
possible just now, and no reason to not support it.


--
Best regards,
Vladimir



reply via email to

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