From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:47576) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1XxzdY-0003zI-HR for qemu-devel@nongnu.org; Mon, 08 Dec 2014 09:50:14 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1XxzdS-0003Ex-BC for qemu-devel@nongnu.org; Mon, 08 Dec 2014 09:50:08 -0500 Received: from mx1.redhat.com ([209.132.183.28]:45239) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1XxzdS-00039r-37 for qemu-devel@nongnu.org; Mon, 08 Dec 2014 09:50:02 -0500 Date: Mon, 8 Dec 2014 15:49:57 +0100 From: Kevin Wolf Message-ID: <20141208144957.GD3792@noname.str.redhat.com> References: <20141205153210.GA4573@localhost.localdomain> <20141208100707.GB3792@noname.str.redhat.com> <20141208135039.GA2836@localhost.localdomain> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20141208135039.GA2836@localhost.localdomain> Subject: Re: [Qemu-devel] qcow2: Can create qcow2 image format on rbd server List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Jun Li Cc: josh.durgin@inktank.com, juli@redhat.com, qemu-devel@nongnu.org, stefanha@redhat.com Am 08.12.2014 um 14:50 hat Jun Li geschrieben: > On Mon, 12/08 11:07, Kevin Wolf wrote: > > Am 05.12.2014 um 16:32 hat Jun Li geschrieben: > > > Currently, qemu-img can not create qcow2 image format on rbd server. Analysis > > > the code as followings: > > > when create qcow2 format image: > > > qcow2_create2 > > > bdrv_create_file(filename, opts, &local_err); --> Here will create a 0 size > > > file(e.g: file1) on rbd server. > > > ... > > > ret = bdrv_pwrite(bs, 0, header, cluster_size); --> So here can not write > > > qcow2 header into file1 due to the file1's length is 0. Seems > > > qemu_rbd_aio_writev can not write beyond EOF. > > > ... > > > > > > As above analysis, there are two methods to solve the above bz as followings: > > > 1, When create file1, just create a fixed-size file1 on rbd server(not 0 size). > > > > This is not a solution. Even if you might be able to create an image > > successfully, using qcow2 without a backend that allows the image file > > to grow is bound to fail sooner or later. > > > > So yes, you'll want to extend the rbd block driver to grow the file > > asynchronously when writing beyond EOF. > > > > Hi Kevin, > > Although rbd_resize is synchronous, I just want to create a new child-thread > to realize asynchronous(Maybe just like userspace aio: libaio) rbd_resize. > Just like following: > > qemu_rbd_aio_writev() > { > if (BlockDriverState->file->growable == 1) { > pthread_create(&thread_id, NULL, child_thread, NULL); > } > > rbd_start_aio(); > } > > child_thread() > { > ... > rbd_resize(); > rbd_start_aio(); > ... > } > > Currently, seems do not have original asynchronous rbd_resize. Besides, rbd block > driver do not support growable file. So I want to use above method to realize > asynchronous rbd_resize() in our qemu level. > > What's your opinion? Are you sure that the rbd libraries are thread-safe and can be used in this way? Kevin