From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:41512) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1UsBMU-0000gI-6A for qemu-devel@nongnu.org; Thu, 27 Jun 2013 08:31:48 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1UsBMN-0005Lm-HX for qemu-devel@nongnu.org; Thu, 27 Jun 2013 08:31:42 -0400 Received: from e28smtp05.in.ibm.com ([122.248.162.5]:42033) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1UsBMM-0005L1-Ss for qemu-devel@nongnu.org; Thu, 27 Jun 2013 08:31:35 -0400 Received: from /spool/local by e28smtp05.in.ibm.com with IBM ESMTP SMTP Gateway: Authorized Use Only! Violators will be prosecuted for from ; Thu, 27 Jun 2013 17:56:24 +0530 Received: from d28relay03.in.ibm.com (d28relay03.in.ibm.com [9.184.220.60]) by d28dlp01.in.ibm.com (Postfix) with ESMTP id A16DEE0053 for ; Thu, 27 Jun 2013 18:01:01 +0530 (IST) Received: from d28av02.in.ibm.com (d28av02.in.ibm.com [9.184.220.64]) by d28relay03.in.ibm.com (8.13.8/8.13.8/NCO v10.0) with ESMTP id r5RCVhhA27721952 for ; Thu, 27 Jun 2013 18:01:44 +0530 Received: from d28av02.in.ibm.com (loopback [127.0.0.1]) by d28av02.in.ibm.com (8.14.4/8.13.1/NCO v10.0 AVout) with ESMTP id r5RCVPTR029832 for ; Thu, 27 Jun 2013 22:31:26 +1000 Message-ID: <51CC304C.80706@linux.vnet.ibm.com> Date: Thu, 27 Jun 2013 20:30:04 +0800 From: Wenchao Xia MIME-Version: 1.0 References: <51C2C465.1090701@linux.vnet.ibm.com> <20130625091300.GA26177@stefanha-thinkpad.redhat.com> <51C97B8B.2010304@linux.vnet.ibm.com> <20130627090139.GC14351@stefanha-thinkpad.redhat.com> In-Reply-To: <20130627090139.GC14351@stefanha-thinkpad.redhat.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit Subject: Re: [Qemu-devel] [RFC] qemu-img: add option -d in convert List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Stefan Hajnoczi Cc: Kevin Wolf , Anthony Liguori , qemu-devel , Paolo Bonzini , Dietmar Maurer 于 2013-6-27 17:01, Stefan Hajnoczi 写道: > On Tue, Jun 25, 2013 at 07:14:19PM +0800, Wenchao Xia wrote: >> 于 2013-6-25 17:13, Stefan Hajnoczi 写道: >>> On Thu, Jun 20, 2013 at 04:59:17PM +0800, Wenchao Xia wrote: >>> >>> If I understand correctly, you have a backing chain with internal >>> snapshots: >>> >>>> imageA(sn0)->imageB(sn0,sn1)->imageC(sn0) >>> >>> And you want to convert this to a chain of external snapshots: >>> >> What it looks like is convert into external snapshots, actually >> requirement is get delta data from internal snapshot, external snapshots >> have delta data by nature so it is a way to orginize it. This patch >> will help get that delta data. > > Copying all the data out into external files in order to get > is_allocated information seems very inefficient. > > We've discussed dirty block tracking APIs on the list several times. > This seems related. > > Maybe it's time to tackle this properly for both external and internal > snapshots. > > The reason why a dirty block tracking API is also helpful is that not > all tools want to learn how to open different image file formats. (Even > with libqblock.) > > The drity block tracking API gives them information which they can use > together with a single interface like NBD or a libvirt block pread-style > interface to read out dirty blocks. Nice to have the dirty block tracking API. As the discuss before, it may be implemented as best effort which kept in memory, and I think it is right because dirty map already exist in some block format, do that in block seems a duplicated implemention. If that API is online, the approach in this patch, would be the backed way to get delta data, when qemu is not shutdown gracefully. What I can think is later additional parameter: -dirty_out file, which will rebuild the dirty info with -d file_compare. For internal snapshot, still I need an easy way to get delta data of historic ones which may have no dirty block tracking info. > > BTW we already have qemu-io -c map which prints out allocation > information for an image file. If that command is extended to support > -s then you can get your info easily. Do you mean use it like: 1 call qemu-io file -c map -s sn0 2 call qemu-io file -c map -s sn1 3 for (offset = 0; offset < len; offset +=512) { if (allocated on sn0) { call qemu-io file read -s sn0, into buf0 } if (allocated on sn1) { call qemu-io file read -s sn1, into buf1 } if strcmp(buf0, buf1) { write down the delta } } ? I think it is workable and flex, the bottle neck is the string parsing of qemu-io. For delta data info retrieving purpose, qemu-img approach would faster. > > Stefan > -- Best Regards Wenchao Xia