Am 11.11.2014 um 10:25 hat Max Reitz geschrieben:
> On 2014-11-11 at 10:22, Kevin Wolf wrote:
> >Am 10.11.2014 um 21:59 hat Eric Blake geschrieben:
> >>On 11/10/2014 06:45 AM, Max Reitz wrote:
> >>>Refcounts may have a width of up to 64 bit, so qemu should use the same
> >>s/bit/bits/
> >>
> >>>width to represent refcount values internally.
> >>>
> >>>Signed-off-by: Max Reitz <mre...@redhat.com>
> >>>---
> >>> block/qcow2-cluster.c | 9 ++++++---
> >>> block/qcow2-refcount.c | 37 ++++++++++++++++++++-----------------
> >>> block/qcow2.h | 7 ++++---
> >>> 3 files changed, 30 insertions(+), 23 deletions(-)
> >>>
> >>>diff --git a/block/qcow2-cluster.c b/block/qcow2-cluster.c
> >>>index df0b2c9..ab43902 100644
> >>>--- a/block/qcow2-cluster.c
> >>>+++ b/block/qcow2-cluster.c
> >>>@@ -1640,7 +1640,7 @@ static int
> >>>expand_zero_clusters_in_l1(BlockDriverState *bs, uint64_t *l1_table,
> >>> for (i = 0; i < l1_size; i++) {
> >>> uint64_t l2_offset = l1_table[i] & L1E_OFFSET_MASK;
> >>> bool l2_dirty = false;
> >>>- int l2_refcount;
> >>>+ int64_t l2_refcount;
> >>You may want to mention in the commit message that you choose a signed
> >>type to allow negative for errors, and therefore we really allow only up
> >>to 63 useful bits. Or even mention that this is okay because no one
> >>can feasibly generate an image with more than 2^63 refs to the same
> >>cluster (there isn't that much storage or time to do such a task in our
> >>lifetime...)
> >Should patch 1 then set refcount_max = 2^63 for refcount order 6?
>
> It does set refcount_max to INT64_MAX (instead of UINT64_MAX, and
> there is a comment above that line why it's the signed maximum).
Right, I should read patches instead of just Eric's reply before I reply
something myself...
Kevin
