aboutsummaryrefslogtreecommitdiff
path: root/block/vmdk.c
diff options
context:
space:
mode:
authorSam Eiderman <shmuel.eiderman@oracle.com>2019-06-20 12:10:56 +0300
committerMax Reitz <mreitz@redhat.com>2019-06-24 15:53:02 +0200
commit59d6ee485020fdc45cb0f9f748d8b8850fad9f8c (patch)
tree4900f29e776a3e46836343141345daa4f5f6cde7 /block/vmdk.c
parent940a2cd5d2eede3c81b83712c55cc6d3c5e6c463 (diff)
downloadqemu-59d6ee485020fdc45cb0f9f748d8b8850fad9f8c.zip
qemu-59d6ee485020fdc45cb0f9f748d8b8850fad9f8c.tar.gz
qemu-59d6ee485020fdc45cb0f9f748d8b8850fad9f8c.tar.bz2
vmdk: Reduce the max bound for L1 table size
512M of L1 entries is a very loose bound, only 32M are required to store the maximal supported VMDK file size of 2TB. Fixed qemu-iotest 59# - now failure occures before on impossible L1 table size. Reviewed-by: Karl Heubaum <karl.heubaum@oracle.com> Reviewed-by: Eyal Moscovici <eyal.moscovici@oracle.com> Reviewed-by: Liran Alon <liran.alon@oracle.com> Reviewed-by: Arbel Moshe <arbel.moshe@oracle.com> Signed-off-by: Sam Eiderman <shmuel.eiderman@oracle.com> Message-id: 20190620091057.47441-3-shmuel.eiderman@oracle.com Reviewed-by: Max Reitz <mreitz@redhat.com> Signed-off-by: Max Reitz <mreitz@redhat.com>
Diffstat (limited to 'block/vmdk.c')
-rw-r--r--block/vmdk.c13
1 files changed, 7 insertions, 6 deletions
diff --git a/block/vmdk.c b/block/vmdk.c
index 0f2e453..931eb27 100644
--- a/block/vmdk.c
+++ b/block/vmdk.c
@@ -425,15 +425,16 @@ static int vmdk_add_extent(BlockDriverState *bs,
error_setg(errp, "Invalid granularity, image may be corrupt");
return -EFBIG;
}
- if (l1_size > 512 * 1024 * 1024) {
+ if (l1_size > 32 * 1024 * 1024) {
/*
* Although with big capacity and small l1_entry_sectors, we can get a
* big l1_size, we don't want unbounded value to allocate the table.
- * Limit it to 512M, which is:
- * 16PB - for default "Hosted Sparse Extent" (VMDK4)
- * cluster size: 64KB, L2 table size: 512 entries
- * 1PB - for default "ESXi Host Sparse Extent" (VMDK3/vmfsSparse)
- * cluster size: 512B, L2 table size: 4096 entries
+ * Limit it to 32M, which is enough to store:
+ * 8TB - for both VMDK3 & VMDK4 with
+ * minimal cluster size: 512B
+ * minimal L2 table size: 512 entries
+ * 8 TB is still more than the maximal value supported for
+ * VMDK3 & VMDK4 which is 2TB.
*/
error_setg(errp, "L1 size too big");
return -EFBIG;