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? Also note that while it might not be feasible to create a cluster with 2^63 references, this doesn't mean that it's impossible to create a cluster with a stored refcount of (more than) 2^63. We'll have to have checks there. Kevin
pgp4LcM8yzvla.pgp
Description: PGP signature
