Re: [Qemu-devel] [RFC] introduce a dynamic library to expose qemu block API

[Wenchao Xia]

> 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.
  I tried to avoid fork() and execv() in the library as much as
possible. Dealing with another program's string output will cost quite
some codes about its timeout or exception error, more "native" code
seems better to me.

> NB, I still think qemu-img info should be able to return a JSON parsable
> data format, regardless of what any block library does.
  An option to qemu-img to specify output format may be a good way.

> Daniel


--
Best Regards

Wenchao Xia