qemu-devel
[Top][All Lists]
Advanced

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

Re: [Qemu-devel] [PATCH v2] qcow2: add update refcount table realization


From: Jun Li
Subject: Re: [Qemu-devel] [PATCH v2] qcow2: add update refcount table realization for update_refcount
Date: Tue, 9 Sep 2014 22:04:31 +0800
User-agent: Mutt/1.5.23 (2014-03-12)

On Tue, 09/09 10:21, Kevin Wolf wrote:
> Am 09.09.2014 um 04:52 hat Jun Li geschrieben:
> > On Fri, 09/05 12:21, Kevin Wolf wrote:
> > > Am 01.09.2014 um 12:52 hat Jun Li geschrieben:
> > > > When every item of refcount block is NULL, free refcount block and 
> > > > reset the
> > > > corresponding item of refcount table with NULL.
> > > > 
> > > > Signed-off-by: Jun Li <address@hidden>
> > > 
> > > The commit message should also describe why this is a relevant
> > > improvement for some use case. My gut feeling is that it complicates the
> > > code for a very minimal gain.
> > 
> > Hi Kevin,
> >   
> >   "Add update refcount table realization for update_refcount" is nesseary 
> > for
> >   qcow2 shrinking. I will submit v3 of "qcow2: Patch for shrinking qcow2 
> > disk
> >   image". When check the code of update_refcount, I find it lacks of this 
> > patch.
> 
> Why is it necessary? Can't you just leave the refcount blocks allocated?
> They shouldn't take a lot of space.
> 

For example:
cluster_size: 64k

We want to shrink a disk from 2T to 1T.

one refcount block which in one cluster size can show 64k / 2B = 32k clusters. 
As 32k * 64k = 2G, so one refcount block will show 2G space. And (2T - 1T) / 2G
= 512. So 512 refcount block will take 512 * 64k = 32M space.

So when we shrink a disk from 2T to 1T, host cluster will leak at least 32M
space(refcount block leak) without this patch.

Above is just an example. For usual test case, we can not hit this host cluster
leak, but when we do qcow2 shrinking, this will lead host cluster leak.

Best Regards,
Jun Li



reply via email to

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