qemu-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Qemu-devel] [PATCH 2/2] docs/qcow2: Correct refcount_block_entries


From: Max Reitz
Subject: Re: [Qemu-devel] [PATCH 2/2] docs/qcow2: Correct refcount_block_entries
Date: Tue, 02 Sep 2014 20:59:55 +0200
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.0

On 30.08.2014 00:37, Eric Blake wrote:
On 08/29/2014 03:45 PM, Max Reitz wrote:
A refblock entry may have a different size than 16 bits, it may even be
smaller than a byte. Correct the refcount_block_entries calculation
accordingly.

Signed-off-by: Max Reitz <address@hidden>
---
  docs/specs/qcow2.txt | 2 +-
  1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/docs/specs/qcow2.txt b/docs/specs/qcow2.txt
index cfbc8b0..531c478 100644
--- a/docs/specs/qcow2.txt
+++ b/docs/specs/qcow2.txt
@@ -183,7 +183,7 @@ blocks and are exactly one cluster in size.
  Given a offset into the image file, the refcount of its cluster can be 
obtained
  as follows:
- refcount_block_entries = (cluster_size / sizeof(uint16_t))
+    refcount_block_entries = (cluster_size / (refcount_bits / 8))

Consider refcount_order == 0 (that is, no shared blocks, ALL blocks have
at most refcount 1).  Then, refcount_bits is (1 << 0) == 1.  But 1/8 in
integer math truncates to 0 (oops, division by zero is undefined); when
in reality, the expression you want here is (cluster_size * 8 /
refcount_bits).

If it is integer division, that is. ;-)

I'm counting on you accepting "cluster_size * 8 / refcount_bits" and not rejecting it because of a possible integer overflow. *g*

Max



reply via email to

[Prev in Thread] Current Thread [Next in Thread]