qemu-devel.nongnu.org archive mirror
 help / color / mirror / Atom feed
From: Sam Eiderman <shmuel.eiderman@oracle.com>
To: kwolf@redhat.com, qemu-block@nongnu.org, qemu-devel@nongnu.org,
	mreitz@redhat.com
Cc: liran.alon@oracle.com, arbel.moshe@oracle.com,
	shmuel.eiderman@oracle.com, eyal.moscovici@oracle.com,
	karl.heubaum@oracle.com
Subject: [Qemu-devel] [PATCH v2 2/3] vmdk: Reduce the max bound for L1 table size
Date: Wed,  5 Jun 2019 15:17:20 +0300	[thread overview]
Message-ID: <20190605121721.29815-3-shmuel.eiderman@oracle.com> (raw)
In-Reply-To: <20190605121721.29815-1-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>
---
 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.13.3



  parent reply	other threads:[~2019-06-05 12:21 UTC|newest]

Thread overview: 9+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-06-05 12:17 [Qemu-devel] [PATCH v2 0/3] vmdk: Add read-only support for the new seSparse format Sam Eiderman
2019-06-05 12:17 ` [Qemu-devel] [PATCH v2 1/3] vmdk: Fix comment regarding max l1_size coverage Sam Eiderman
2019-06-19 17:10   ` Max Reitz
2019-06-05 12:17 ` Sam Eiderman [this message]
2019-06-19 17:09   ` [Qemu-devel] [PATCH v2 2/3] vmdk: Reduce the max bound for L1 table size Max Reitz
2019-06-05 12:17 ` [Qemu-devel] [PATCH v2 3/3] vmdk: Add read-only support for seSparse snapshots Sam Eiderman
2019-06-19 17:12   ` Max Reitz
2019-06-20  8:48     ` Sam Eiderman
2019-06-19  9:31 ` [Qemu-devel] [PATCH v2 0/3] vmdk: Add read-only support for the new seSparse format Sam Eiderman

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=20190605121721.29815-3-shmuel.eiderman@oracle.com \
    --to=shmuel.eiderman@oracle.com \
    --cc=arbel.moshe@oracle.com \
    --cc=eyal.moscovici@oracle.com \
    --cc=karl.heubaum@oracle.com \
    --cc=kwolf@redhat.com \
    --cc=liran.alon@oracle.com \
    --cc=mreitz@redhat.com \
    --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).