From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:41977) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Xyi5v-0000rE-HT for qemu-devel@nongnu.org; Wed, 10 Dec 2014 09:18:28 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1Xyi5q-0004WX-84 for qemu-devel@nongnu.org; Wed, 10 Dec 2014 09:18:23 -0500 Received: from mail-pa0-x22a.google.com ([2607:f8b0:400e:c03::22a]:39199) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Xyi5q-0004WL-1l for qemu-devel@nongnu.org; Wed, 10 Dec 2014 09:18:18 -0500 Received: by mail-pa0-f42.google.com with SMTP id et14so2898475pad.29 for ; Wed, 10 Dec 2014 06:18:17 -0800 (PST) Date: Wed, 10 Dec 2014 22:18:08 +0800 From: Jun Li Message-ID: <20141210141808.GB3040@localhost.localdomain> References: <20141205153210.GA4573@localhost.localdomain> <20141208100707.GB3792@noname.str.redhat.com> <20141208135039.GA2836@localhost.localdomain> <20141208144957.GD3792@noname.str.redhat.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20141208144957.GD3792@noname.str.redhat.com> 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: Kevin Wolf Cc: josh.durgin@inktank.com, juli@redhat.com, qemu-devel@nongnu.org, stefanha@redhat.com On Mon, 12/08 15:49, Kevin Wolf wrote: > 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? > I have tested this method, seems it's not thread-safe. Gdb debug info just as followings: # gdb --args /opt/qemu-git-arm/bin/qemu-img create -f qcow2 rbd:qemu-kvm-pool/juli-test44.qcow2:mon_host=$IP 10M (gdb) bt #0 librbd::resize (ictx=0x48fffe948fe80574, size=120095921237475840, prog_ctx=...) at librbd/internal.cc:1492 #1 0x00007ffff7478bb2 in rbd_resize (image=, size=) at librbd/librbd.cc:726 #2 0x00005555555cfa9c in qemu_rbd_truncate (bs=0x7ffff7f9ca00, offset=120095921237475840) at block/rbd.c:798 #3 0x00005555555cf797 in thread_info (t_parameters=0x7ffff7f9c9d0) at block/rbd.c:706 #4 0x00007ffff1c5bee5 in start_thread (arg=0x7fffd5ffb700) at pthread_create.c:309 #5 0x00007ffff198ab8d in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:111 Regards, Jun Li