ping On Thu 27 Aug 2020 04:53:50 PM CEST, Alberto Garcia wrote: > Since commit c8bb23cbdbe32f5c326365e0a82e1b0e68cdcd8a when a write > request results in a new allocation QEMU first tries to see if the > rest of the cluster outside the written area contains only zeroes. > > In that case, instead of doing a normal copy-on-write operation and > writing explicit zero buffers to disk, the code zeroes the whole > cluster efficiently using pwrite_zeroes() with BDRV_REQ_NO_FALLBACK. > > This improves performance very significantly but it only happens when > we are writing to an area that was completely unallocated before. Zero > clusters (QCOW2_CLUSTER_ZERO_*) are treated like normal clusters and > are therefore slower to allocate. > > This happens because the code uses bdrv_is_allocated_above() rather > bdrv_block_status_above(). The former is not as accurate for this > purpose but it is faster. However in the case of qcow2 the underlying > call does already report zero clusters just fine so there is no reason > why we cannot use that information. > > After testing 4KB writes on an image that only contains zero clusters > this patch results in almost five times more IOPS.
Berto