From: Max Reitz <mreitz@redhat.com>
To: qemu-block@nongnu.org
Cc: Kevin Wolf <kwolf@redhat.com>,
Peter Maydell <peter.maydell@linaro.org>,
qemu-devel@nongnu.org, Max Reitz <mreitz@redhat.com>
Subject: [Qemu-devel] [PULL v2 5/8] vmdk: Reduce the max bound for L1 table size
Date: Mon, 24 Jun 2019 16:47:37 +0200 [thread overview]
Message-ID: <20190624144740.5338-6-mreitz@redhat.com> (raw)
In-Reply-To: <20190624144740.5338-1-mreitz@redhat.com>
From: Sam Eiderman <shmuel.eiderman@oracle.com>
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>
---
block/vmdk.c | 13 +++++++------
tests/qemu-iotests/059.out | 2 +-
2 files changed, 8 insertions(+), 7 deletions(-)
diff --git a/block/vmdk.c b/block/vmdk.c
index 0f2e453bf5..931eb2759c 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;
diff --git a/tests/qemu-iotests/059.out b/tests/qemu-iotests/059.out
index f51394ae8e..4fab42a28c 100644
--- a/tests/qemu-iotests/059.out
+++ b/tests/qemu-iotests/059.out
@@ -2358,5 +2358,5 @@ Offset Length Mapped to File
0x140000000 0x10000 0x50000 TEST_DIR/t-s003.vmdk
=== Testing afl image with a very large capacity ===
-qemu-img: Can't get image size 'TEST_DIR/afl9.IMGFMT': File too large
+qemu-img: Could not open 'TEST_DIR/afl9.IMGFMT': L1 size too big
*** done
--
2.21.0
next prev parent reply other threads:[~2019-06-24 14:51 UTC|newest]
Thread overview: 13+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-06-24 14:47 [Qemu-devel] [PULL v2 0/8] Block patches Max Reitz
2019-06-24 14:47 ` [Qemu-devel] [PULL v2 1/8] nvme: do not advertise support for unsupported arbitration mechanism Max Reitz
2019-06-24 14:47 ` [Qemu-devel] [PULL v2 2/8] blockdev: enable non-root nodes for transaction drive-backup source Max Reitz
2019-06-24 14:47 ` [Qemu-devel] [PULL v2 3/8] iotest 134: test cluster-misaligned encrypted write Max Reitz
2019-06-24 14:47 ` [Qemu-devel] [PULL v2 4/8] vmdk: Fix comment regarding max l1_size coverage Max Reitz
2019-06-24 14:47 ` Max Reitz [this message]
2019-06-24 14:47 ` [Qemu-devel] [PULL v2 6/8] vmdk: Add read-only support for seSparse snapshots Max Reitz
2019-07-02 19:13 ` Peter Maydell
2019-07-02 19:46 ` Max Reitz
2019-07-04 16:59 ` Peter Maydell
2019-06-24 14:47 ` [Qemu-devel] [PULL v2 7/8] ssh: switch from libssh2 to libssh Max Reitz
2019-06-24 14:47 ` [Qemu-devel] [PULL v2 8/8] iotests: Fix 205 for concurrent runs Max Reitz
2019-07-01 12:03 ` [Qemu-devel] [PULL v2 0/8] Block patches Peter Maydell
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20190624144740.5338-6-mreitz@redhat.com \
--to=mreitz@redhat.com \
--cc=kwolf@redhat.com \
--cc=peter.maydell@linaro.org \
--cc=qemu-block@nongnu.org \
--cc=qemu-devel@nongnu.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).