diff options
author | Alberto Garcia | 2019-08-16 14:17:42 +0200 |
---|---|---|
committer | Kevin Wolf | 2019-09-10 08:58:43 +0200 |
commit | b70d08205b2e4044c529eefc21df2c8ab61b473b (patch) | |
tree | b079ab4a726f54350274991af4b47b34101c3017 /include/block/blockjob_int.h | |
parent | Merge remote-tracking branch 'remotes/huth-gitlab/tags/m68k-pull-2019-09-07' ... (diff) | |
download | qemu-b70d08205b2e4044c529eefc21df2c8ab61b473b.tar.gz qemu-b70d08205b2e4044c529eefc21df2c8ab61b473b.tar.xz qemu-b70d08205b2e4044c529eefc21df2c8ab61b473b.zip |
qcow2: Fix the calculation of the maximum L2 cache size
The size of the qcow2 L2 cache defaults to 32 MB, which can be easily
larger than the maximum amount of L2 metadata that the image can have.
For example: with 64 KB clusters the user would need a qcow2 image
with a virtual size of 256 GB in order to have 32 MB of L2 metadata.
Because of that, since commit b749562d9822d14ef69c9eaa5f85903010b86c30
we forbid the L2 cache to become larger than the maximum amount of L2
metadata for the image, calculated using this formula:
uint64_t max_l2_cache = virtual_disk_size / (s->cluster_size / 8);
The problem with this formula is that the result should be rounded up
to the cluster size because an L2 table on disk always takes one full
cluster.
For example, a 1280 MB qcow2 image with 64 KB clusters needs exactly
160 KB of L2 metadata, but we need 192 KB on disk (3 clusters) even if
the last 32 KB of those are not going to be used.
However QEMU rounds the numbers down and only creates 2 cache tables
(128 KB), which is not enough for the image.
A quick test doing 4KB random writes on a 1280 MB image gives me
around 500 IOPS, while with the correct cache size I get 16K IOPS.
Cc: qemu-stable@nongnu.org
Signed-off-by: Alberto Garcia <berto@igalia.com>
Signed-off-by: Kevin Wolf <kwolf@redhat.com>
Diffstat (limited to 'include/block/blockjob_int.h')
0 files changed, 0 insertions, 0 deletions