diff options
| author | Sam Eiderman <shmuel.eiderman@oracle.com> | 2019-06-20 12:10:56 +0300 |
|---|---|---|
| committer | Max Reitz <mreitz@redhat.com> | 2019-06-24 15:53:02 +0200 |
| commit | 59d6ee485020fdc45cb0f9f748d8b8850fad9f8c (patch) | |
| tree | 4900f29e776a3e46836343141345daa4f5f6cde7 /block/vmdk.c | |
| parent | 940a2cd5d2eede3c81b83712c55cc6d3c5e6c463 (diff) | |
| download | qemu-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.c | 13 |
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; |