On 07/26/2014 01:22 PM, Max Reitz wrote: > The only really time-consuming operation potentially performed by > qcow2_amend_options() is zero cluster expansion when downgrading qcow2 > images from compat=1.1 to compat=0.10, so report status of that > operation and that operation only through the status CB. > > For this, approximate the progress as the number of L1 entries visited > during the operation. > > Signed-off-by: Max Reitz <mre...@redhat.com> > --- > block/qcow2-cluster.c | 36 ++++++++++++++++++++++++++++++++---- > block/qcow2.c | 9 ++++----- > block/qcow2.h | 3 ++- > 3 files changed, 38 insertions(+), 10 deletions(-)
Seems like a reasonable approximation. The progress may appear to change non-linearly (slower when a sequence of L1 entries visit all-zero data, faster when the entries visit normal data), but we never promised linear growth. > > diff --git a/block/qcow2-cluster.c b/block/qcow2-cluster.c > index 4208dc0..f8bec6f 100644 > --- a/block/qcow2-cluster.c > +++ b/block/qcow2-cluster.c > @@ -1548,10 +1548,17 @@ fail: > * zero expansion (i.e., has been filled with zeroes and is referenced from > an > * L2 table). nb_clusters contains the total cluster count of the image file, > * i.e., the number of bits in expanded_clusters. > + * > + * l1_entries and *visited_l1_entries are ued to keep track of progress for s/ued/used/ Definitely looks simpler than your other approach. -- Eric Blake eblake redhat com +1-919-301-3266 Libvirt virtualization library http://libvirt.org
signature.asc
Description: OpenPGP digital signature