Re: Usage of rbd

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Hi

I also trying to use rbd in my environment, following the wiki's instruction.
and I did "ceph class activate rbd 1.2", but still not works.



My situation:

# mkcephfs -c /usr/local/etc/ceph/ceph.conf --allhosts --mkbtrfs
# /etc/init.d/ceph -c /usr/local/etc/ceph/ceph.conf --allhosts start
# cclass -a
# ceph class activate rbd 1.2
(snip)
10.09.29_09:01:30.047510 mon <- [class,activate,rbd,1.2]
(snip)
10.09.29_09:01:31.067373 mon0 -> 'updated' (0)

# ceph class list
(snip)
mon <- [class,list]
192.168.101.41:0/2359 --> mon0 192.168.101.41:6789/0 --
mon_command(class list v 0) v1 -- ?+0 0x1d4ce30
192.168.101.41:0/2359 <== mon0 192.168.101.41:6789/0 4 ====
mon_command_ack([class,list]=0 installed classes:
rbd (v1.2 [x86-64]) [active]
 v3) v1 ==== 96+0+0 (1704564143 0 0) 0x7f0268000bf0
10.09.29_09:01:44.151874 mon0 -> 'installed classes:
rbd (v1.2 [x86-64]) [active]
' (0)


-* looks like OK. create new pool named "testpool", and make
-* new image named "testdata" in it.


# rados lspools
(snip)
data
metadata
casdata
rbd

# rados mkpool testpool
(snip)
successfully created pool testpool


# rbd -p testpool create testdata --size 128
:/2428 messenger.start
:/2428 --> mon0 192.168.101.41:6789/0 -- auth(proto 0 30 bytes) v1 --
?+0 0x25cfe10
192.168.101.41:0/2428 learned my addr 192.168.101.41:0/2428
192.168.101.41:0/2428 <== mon0 192.168.101.41:6789/0 1 ====
auth_reply(proto 1 0 Success) v1 ==== 24+0+0 (1462504351 0 0)
0x7ff88c000940
192.168.101.41:0/2428 --> mon0 192.168.101.41:6789/0 --
mon_subscribe({monmap=0+}) v1 -- ?+0 0x25d57d0
192.168.101.41:0/2428 --> mon0 192.168.101.41:6789/0 --
mon_subscribe({monmap=0+,osdmap=0}) v1 -- ?+0 0x25d59b0
192.168.101.41:0/2428 --> mon0 192.168.101.41:6789/0 --
mon_subscribe({monmap=0+,osdmap=0}) v1 -- ?+0 0x25d4180
192.168.101.41:0/2428 <== mon0 192.168.101.41:6789/0 2 ==== mon_map v1
==== 191+0+0 (3527398169 0 0) 0x7ff88c000c40
192.168.101.41:0/2428 <== mon0 192.168.101.41:6789/0 3 ====
mon_subscribe_ack(300s) v1 ==== 20+0+0 (388814775 0 0) 0x7ff88c000920
192.168.101.41:0/2428 <== mon0 192.168.101.41:6789/0 4 ==== mon_map v1
==== 191+0+0 (3527398169 0 0) 0x7ff88c000bf0
192.168.101.41:0/2428 <== mon0 192.168.101.41:6789/0 5 ====
osd_map(5,5) v1 ==== 1153+0+0 (1530501066 0 0) 0x7ff88c000920
192.168.101.41:0/2428 <== mon0 192.168.101.41:6789/0 6 ====
mon_subscribe_ack(300s) v1 ==== 20+0+0 (388814775 0 0) 0x7ff88c000920
192.168.101.41:0/2428 <== mon0 192.168.101.41:6789/0 7 ==== mon_map v1
==== 191+0+0 (3527398169 0 0) 0x7ff88c000bf0
192.168.101.41:0/2428 <== mon0 192.168.101.41:6789/0 8 ====
osd_map(5,5) v1 ==== 1153+0+0 (1530501066 0 0) 0x7ff88c000920
192.168.101.41:0/2428 --> osd0 192.168.101.41:6801/2231 --
osd_op(client4104.0:1 testdata.rbd [stat 0~0] 4.49b3) v1 -- ?+0
0x25d43c0
192.168.101.41:0/2428 <== mon0 192.168.101.41:6789/0 9 ====
mon_subscribe_ack(300s) v1 ==== 20+0+0 (388814775 0 0) 0x7ff88c0011e0
192.168.101.41:0/2428 <== osd0 192.168.101.41:6801/2231 1 ====
osd_op_reply(1 testdata.rbd [stat 0~0] = -2 (No such file or
directory)) v1 ==== 98+0+0 (1237653720 0 0) 0x7ff87c000990
192.168.101.41:0/2428 --> osd0 192.168.101.41:6801/2231 --
osd_op(client4104.0:2 rbd_info [write 0~0] 4.573a) v1 -- ?+0 0x25d43c0
192.168.101.41:0/2428 <== osd0 192.168.101.41:6801/2231 2 ====
osd_op_reply(2 rbd_info [write 0~0] = 0) v1 ==== 94+0+0 (3894334133 0
0) 0x7ff87c000990
192.168.101.41:0/2428 --> osd0 192.168.101.41:6801/2231 --
osd_op(client4104.0:3 rbd_info [call rbd.assign_bid] 4.573a) v1 -- ?+0
0x25d43a0
192.168.101.41:0/2428 --> mon0 192.168.101.41:6789/0 --
mon_subscribe({monmap=2+,osdmap=6}) v1 -- ?+0 0x7ff874000a90
192.168.101.41:0/2428 --> osd0 192.168.101.41:6801/2231 -- ping v1 --
?+0 0x7ff874000d20
192.168.101.41:0/2428 <== mon0 192.168.101.41:6789/0 10 ====
mon_subscribe_ack(300s) v1 ==== 20+0+0 (388814775 0 0) 0x7ff88c000920
192.168.101.41:0/2428 --> osd0 192.168.101.41:6801/2231 -- ping v1 --
?+0 0x7ff874000d20

-* rbd command doesnt return, the ping v1 log continues.
-* mon0, mds0, osd0 are on the same machine and they work well in ceph
fuse environment.
-* the result is same if i change testpool to rbd...

2010/9/29 Yehuda Sadeh Weinraub <yehudasa@xxxxxxxxx>:
> On Tue, Sep 28, 2010 at 8:55 AM, Takuya ASADA <syuu@xxxxxxxxxxxx> wrote:
>>
>> Hi,
>>
>> I'm trying to test kvm-rbd, and I just failed to create image on it.
>> I followed installation sequence on the wiki
>> (http://ceph.newdream.net/wiki/Kvm-rbd),
>> and executed
>> $ qemu-img create -f rbd rbd:data/foo 10G
>> it returned
>>
>> failed assigning block id
>> qemu-img: rbd:data/foo: error while creating rbd: Input/output error
>>
>> Then I looked into source code, and realized maybe I need to load libcls_rbd.so,
>> so I executed
>> $ cclass -a
>> $ ceph class list
>> rbd class shows up.
>>
>> 10.09.29_00:55:53.939866 mon <- [class,list]
>> 10.09.29_00:55:53.940230 mon0 -> 'installed classes:
>> rbd (v1.2 [x86-64])
>> ' (0)
>>
>> Then I tried "qemu-img create" again, also "rbd create", it didn't work at all.
>> Like this:
>>
>> $ rbd -p hoge99 --size 10 create test.img
>> failed to assign a block name for image
>> create error: Operation not supported
>>
>> $ qemu-img create -f rbd rbd:data/foo 10G
>> Formatting 'rbd:data/foo', fmt=rbd size=10737418240 cluster_size=0
>> failed assigning block id
>> qemu-img: rbd:data/foo: error while creating rbd: Input/output error
>>
>> osd and mon are working correctly, I can use it via rados command and librados.
>>
>> My question is:
>> - Am I missing something to start using rbd?
>
> The rbd class is loaded but not activated. You can run 'ceph class
> activate rbd 1.2', it should fix it (note that it takes a minute to
> propagate).
>
>>
>> - Do I need rbd kernel module for kvm-rbd?
>> I thought it's just a userland application, which calling librados.
>>
> It is a userland application, and you don't need any kernel module.
>
> Thanks,
> Yehuda
> --
> To unsubscribe from this list: send the line "unsubscribe ceph-devel" in
> the body of a message to majordomo@xxxxxxxxxxxxxxx
> More majordomo info at Âhttp://vger.kernel.org/majordomo-info.html
>

-- 
Software Laboratory, Graduate school of Systems and Information
Engineering, Univ. of Tsukuba.
Shingo TAKADA
--
To unsubscribe from this list: send the line "unsubscribe ceph-devel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html


[Index of Archives]     [CEPH Users]     [Ceph Large]     [Information on CEPH]     [Linux BTRFS]     [Linux USB Devel]     [Video for Linux]     [Linux Audio Users]     [Yosemite News]     [Linux Kernel]     [Linux SCSI]

  Powered by Linux