From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([208.118.235.92]:54300) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1SpcTG-0003AV-Vo for qemu-devel@nongnu.org; Fri, 13 Jul 2012 05:47:40 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1SpcTA-0007YV-V4 for qemu-devel@nongnu.org; Fri, 13 Jul 2012 05:47:34 -0400 Received: from e06smtp18.uk.ibm.com ([195.75.94.114]:51685) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1SpcTA-0007YK-N2 for qemu-devel@nongnu.org; Fri, 13 Jul 2012 05:47:28 -0400 Received: from /spool/local by e06smtp18.uk.ibm.com with IBM ESMTP SMTP Gateway: Authorized Use Only! Violators will be prosecuted for from ; Fri, 13 Jul 2012 10:47:27 +0100 Received: from d06av07.portsmouth.uk.ibm.com (d06av07.portsmouth.uk.ibm.com [9.149.37.248]) by d06nrmr1507.portsmouth.uk.ibm.com (8.13.8/8.13.8/NCO v10.0) with ESMTP id q6D9lO8F2179226 for ; Fri, 13 Jul 2012 10:47:24 +0100 Received: from d06av07.portsmouth.uk.ibm.com (d06av07.portsmouth.uk.ibm.com [127.0.0.1]) by d06av07.portsmouth.uk.ibm.com (8.14.4/8.13.1/NCO v10.0 AVout) with ESMTP id q6D9T3tU003663 for ; Fri, 13 Jul 2012 05:29:03 -0400 Date: Fri, 13 Jul 2012 10:47:23 +0100 From: Stefan Hajnoczi Message-ID: <20120713094723.GB16172@stefanha-thinkpad.localdomain> References: <4FFA9C30.2070201@linux.vnet.ibm.com> <20120709092705.GG16198@redhat.com> <4FFBBF8C.8080708@linux.vnet.ibm.com> <4FFBD729.8000309@redhat.com> <20120713091247.GA15503@stefanha-thinkpad.localdomain> <20120713091640.GD2317@redhat.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20120713091640.GD2317@redhat.com> Subject: Re: [Qemu-devel] [RFC] introduce a dynamic library to expose qemu block API List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: "Daniel P. Berrange" Cc: Paolo Bonzini , Anthony Liguori , Wenchao Xia , qemu-devel@nongnu.org On Fri, Jul 13, 2012 at 10:16:40AM +0100, Daniel P. Berrange wrote: > On Fri, Jul 13, 2012 at 10:12:47AM +0100, Stefan Hajnoczi wrote: > > On Tue, Jul 10, 2012 at 09:18:01AM +0200, Paolo Bonzini wrote: > > > Il 10/07/2012 07:37, Wenchao Xia ha scritto: > > > >> > > > >> For getting the other metadata about the disk image you mention, another > > > >> possibility to is just make 'qemu-img info' return the data in a machine > > > >> parseable format, ie JSON& make a client API for extracting data from > > > >> this JSON document. > > > >> > > > > Thank u for the idea. The .so is introduced to let program access the > > > > image more directly, parsing string is not so fast and it depends on > > > > another program's stdout output, I hope to get a faster way. > > > > > > I doubt you actually have profiled it. > > > > I think speed is not the issue, instead it's just providing an API that > > external programs can use. Management tools, backup software, custom > > administration tools, etc. It's convenient to have an API. > > Actually I think speed could well be quite relevant. In large deployments > it would not be surpising to see 1000's of images in a directory. If you > want to be able to query metadata about all of them at once, then being > able to open()+read(4k)+close() 1000 times is going to be dramatically > faster than doing fork()+execve(qemu-img) 1000 times. Yes, that's true. For situations like querying a whole repository of image files speed matters. I still think that we should focus on the API first. Whether the .so forks qemu-nbd/qemu-img or includes the actual block layer code only matters once we are satisfied that this library is useful and works. And for applications that use qemu-img today there won't be a speed decrease, at least. Stefan