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.
Max
