Re: [Qemu-devel] [PATCH v2 1/2] rbd: use the higher level librbd instead of just librados

[Stefan Hajnoczi <stefanha@gmail.com>]

On Tue, Apr 12, 2011 at 1:18 AM, Josh Durgin <josh.durgin@dreamhost.com> wrote:
> On 04/08/2011 01:43 AM, Stefan Hajnoczi wrote:
>>
>> On Mon, Mar 28, 2011 at 04:15:57PM -0700, Josh Durgin wrote:
>>>
>>> librbd stacks on top of librados to provide access
>>> to rbd images.
>>>
>>> Using librbd simplifies the qemu code, and allows
>>> qemu to use new versions of the rbd format
>>> with few (if any) changes.
>>>
>>> Signed-off-by: Josh Durgin<josh.durgin@dreamhost.com>
>>> Signed-off-by: Yehuda Sadeh<yehuda@hq.newdream.net>
>>> ---
>>>  block/rbd.c       |  785
>>> +++++++++++++++--------------------------------------
>>>  block/rbd_types.h |   71 -----
>>>  configure         |   33 +--
>>>  3 files changed, 221 insertions(+), 668 deletions(-)
>>>  delete mode 100644 block/rbd_types.h
>>
>> Hi Josh,
>> I have applied your patches onto qemu.git/master and am running
>> ceph.git/master.
>>
>> Unfortunately qemu-iotests fails for me.
>>
>>
>> Test 016 seems to hang in qemu-io -g -c write -P 66 128M 512
>> rbd:rbd/t.raw.  I can reproduce this consistently.  Here is the
>> backtrace of the hung process (not consuming CPU, probably deadlocked):
>
> This hung because it wasn't checking the return value of rbd_aio_write.
> I've fixed this in the for-qemu branch of
> http://ceph.newdream.net/git/qemu-kvm.git. Also, the existing rbd
> implementation is not 'growable' - writing to a large offset will not expand
> the rbd image correctly. Should we implement bdrv_truncate to support this
> (librbd has a resize operation)? Is bdrv_truncate useful outside of qemu-img
> and qemu-io?

If librbd has a resize operation then it would be nice to wire up
bdrv_truncate() for completeness.  Note that bdrv_truncate() can also
be called online using the block_resize monitor command.

Since rbd devices are not growable we should fix qemu-iotests to skip
016 for rbd.

>> Test 008 failed with an assertion but succeeded when run again.  I think
>> this is a race condition:
>
> This is likely a use-after-free, but I haven't been able to find the race
> condition yet (or reproduce it). Could you get a backtrace from the core
> file?

Unfortunately I have no core file and wasn't able to reproduce it again.

Is qemu-iotests passing for you now?

Stefan