rbd create command fails to create image

rbd create command fails to create image

[Xiaoguang Liu]

unstable branch,  build on Fedora 13.


[root@ceph-1 mnt]# rbd create foo --size 1024
failed to assign a block name for image
create error: Operation not supported
[root@ceph-1 mnt]# rbd list
pool rbd doesn't contain rbd images

Re: rbd create command fails to create image

[Yehuda Sadeh Weinraub]

On Thu, Aug 5, 2010 at 11:50 PM, Xiaoguang Liu <syslxg@gmail.com> wrote:
> unstable branch,  build on Fedora 13.
>
>
> [root@ceph-1 mnt]# rbd create foo --size 1024
> failed to assign a block name for image
> create error: Operation not supported

This happens because the osd doesn't have the rbd class loaded in, or
have an older version loaded in. The rbd class is a loadable library
that handles some of the rbd header manipulation, as well as assigning
a unique block names for the specific rbd image. The list of classes
in the system can be obtained by running:

$ ./ceph class list
10.08.06_00:35:17.213413 mon <- [class,list]
10.08.06_00:35:17.214044 mon1 -> 'installed classes:
rbd (v1.2 [x86-64]) [active]
' (0)

Currently we'd expect rbd class version 1.2 to be loaded in and activated.

Loading a class can be done by the cclass utility, e.g.:
$ cclass -a

This will try to load all the classes that were installed with they
system, usually at /usr/lib/rados-classes. This is only needed to be
run once (per architecture) as long as there's no need to update the
class.

Yehuda
--
To unsubscribe from this list: send the line "unsubscribe ceph-devel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: rbd create command fails to create image

[Xiaoguang Liu]

you are right. I don't have any classes installed. but cclass -a
fails. what could be the causes?

[root@ceph-1 x86_64]# cclass -a
nm: /usr/lib64/rados-classes/libcls_rbd.so.1.0.0: no symbols
Loading class: /usr/lib64/rados-classes/libcls_rbd.so.1.0.0: Error:
Could not detect class name
nm: /usr/lib64/rados-classes/libcls_rbd.so.1.0.0: no symbols
read 37096 bytes from /usr/lib64/rados-classes/libcls_rbd.so.1.0.0
10.08.06_15:32:25.472987 mon <-
[class,add,Error:,Could,not,detect,class,name,changed]
10.08.06_15:32:25.473399 mon0 -> 'invalid option: detect' (-22)

[root@ceph-1 x86_64]# ceph class list
10.08.06_15:32:55.087874 mon <- [class,list]
10.08.06_15:32:55.088179 mon0 -> 'no installed classes!' (0)




On Fri, Aug 6, 2010 at 3:10 PM, Yehuda Sadeh Weinraub
<yehudasa@gmail.com> wrote:
> On Thu, Aug 5, 2010 at 11:50 PM, Xiaoguang Liu <syslxg@gmail.com> wrote:
>> unstable branch,  build on Fedora 13.
>>
>>
>> [root@ceph-1 mnt]# rbd create foo --size 1024
>> failed to assign a block name for image
>> create error: Operation not supported
>
> This happens because the osd doesn't have the rbd class loaded in, or
> have an older version loaded in. The rbd class is a loadable library
> that handles some of the rbd header manipulation, as well as assigning
> a unique block names for the specific rbd image. The list of classes
> in the system can be obtained by running:
>
> $ ./ceph class list
> 10.08.06_00:35:17.213413 mon <- [class,list]
> 10.08.06_00:35:17.214044 mon1 -> 'installed classes:
> rbd (v1.2 [x86-64]) [active]
> ' (0)
>
> Currently we'd expect rbd class version 1.2 to be loaded in and activated.
>
> Loading a class can be done by the cclass utility, e.g.:
> $ cclass -a
>
> This will try to load all the classes that were installed with they
> system, usually at /usr/lib/rados-classes. This is only needed to be
> run once (per architecture) as long as there's no need to update the
> class.
>
> Yehuda
>
--
To unsubscribe from this list: send the line "unsubscribe ceph-devel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: rbd create command fails to create image

[Sage Weil]

Hi Xiaoguang,

The problem is that /usr/lib/rados-classes/* shouldn't have symbols 
stripped.  I'm no rpmbuild expert, but a search for 'rpmbuild strip' 
turned up a few things.  Can you see if the below patch fixes the problem 
for you?

Thanks!
sage


diff --git a/ceph.spec.in b/ceph.spec.in
index 20e0251..f068edd 100644
--- a/ceph.spec.in
+++ b/ceph.spec.in
@@ -64,6 +64,7 @@ conjunction with any FastCGI capable web server.
 make -j$(getconf _NPROCESSORS_ONLN) CFLAGS="$RPM_OPT_FLAGS" CXXFLAGS="$RPM_OPT_FLAGS"
 
 %install
+export DONT_STRIP=1
 rm -rf $RPM_BUILD_ROOT
 make install DESTDIR=$RPM_BUILD_ROOT
 find $RPM_BUILD_ROOT -type f -name "*.la" -exec rm -f {} ';'

Re: rbd create command fails to create image

[Thomas Mueller]

Am Fri, 06 Aug 2010 09:44:16 -0700 schrieb Sage Weil:

> Hi Xiaoguang,
> 
> The problem is that /usr/lib/rados-classes/* shouldn't have symbols
> stripped.  I'm no rpmbuild expert, but a search for 'rpmbuild strip'
> turned up a few things.  Can you see if the below patch fixes the
> problem for you?
> 
> Thanks!
> sage
> 
> 
> diff --git a/ceph.spec.in b/ceph.spec.in index 20e0251..f068edd 100644
> --- a/ceph.spec.in
> +++ b/ceph.spec.in
> @@ -64,6 +64,7 @@ conjunction with any FastCGI capable web server.
>  make -j$(getconf _NPROCESSORS_ONLN) CFLAGS="$RPM_OPT_FLAGS"
>  CXXFLAGS="$RPM_OPT_FLAGS"
>  
>  %install
> +export DONT_STRIP=1
>  rm -rf $RPM_BUILD_ROOT
>  make install DESTDIR=$RPM_BUILD_ROOT
>  find $RPM_BUILD_ROOT -type f -name "*.la" -exec rm -f {} ';'

I'm not a rpm expert either. :) but grepping /usr/lib/rpm did not reveal 
any DONT_STRIP information. 

the strip'ing is done by "%__os_install_post" macro:

%__os_install_post        \
      /usr/lib/rpm/brp-compress \
      /usr/lib/rpm/brp-strip \
      /usr/lib/rpm/brp-strip-comment-note \

maybe redefining it in spec like this:

%define __os_install_post /usr/lib/rpm/brp-compress

may help?

either way, it disables strip'ing for all the files. Is this good? :)

- Thomas

Re: rbd create command fails to create image

[Xiaoguang Liu]

I tried both ways. none of them worked.

BTW, Yehuda said the new class should be v1.2. why I saw 1.0.0 in the
error message:

Loading class: /usr/lib64/rados-classes/libcls_rbd.so.1.0.0: Error:
Could not detect class name.




On Sat, Aug 7, 2010 at 7:38 PM, Thomas Mueller <thomas@chaschperli.ch> wrote:
> Am Fri, 06 Aug 2010 09:44:16 -0700 schrieb Sage Weil:
>
>> Hi Xiaoguang,
>>
>> The problem is that /usr/lib/rados-classes/* shouldn't have symbols
>> stripped.  I'm no rpmbuild expert, but a search for 'rpmbuild strip'
>> turned up a few things.  Can you see if the below patch fixes the
>> problem for you?
>>
>> Thanks!
>> sage
>>
>>
>> diff --git a/ceph.spec.in b/ceph.spec.in index 20e0251..f068edd 100644
>> --- a/ceph.spec.in
>> +++ b/ceph.spec.in
>> @@ -64,6 +64,7 @@ conjunction with any FastCGI capable web server.
>>  make -j$(getconf _NPROCESSORS_ONLN) CFLAGS="$RPM_OPT_FLAGS"
>>  CXXFLAGS="$RPM_OPT_FLAGS"
>>
>>  %install
>> +export DONT_STRIP=1
>>  rm -rf $RPM_BUILD_ROOT
>>  make install DESTDIR=$RPM_BUILD_ROOT
>>  find $RPM_BUILD_ROOT -type f -name "*.la" -exec rm -f {} ';'
>
> I'm not a rpm expert either. :) but grepping /usr/lib/rpm did not reveal
> any DONT_STRIP information.
>
> the strip'ing is done by "%__os_install_post" macro:
>
> %__os_install_post        \
>      /usr/lib/rpm/brp-compress \
>      /usr/lib/rpm/brp-strip \
>      /usr/lib/rpm/brp-strip-comment-note \
>
> maybe redefining it in spec like this:
>
> %define __os_install_post /usr/lib/rpm/brp-compress
>
> may help?
>
> either way, it disables strip'ing for all the files. Is this good? :)
>
> - Thomas
>
>
> --
> To unsubscribe from this list: send the line "unsubscribe ceph-devel" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
>
--
To unsubscribe from this list: send the line "unsubscribe ceph-devel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: rbd create command fails to create image

[Yehuda Sadeh Weinraub]

On Sun, Aug 8, 2010 at 8:04 PM, Xiaoguang Liu <syslxg@gmail.com> wrote:
> I tried both ways. none of them worked.
>
> BTW, Yehuda said the new class should be v1.2. why I saw 1.0.0 in the
> error message:
>
> Loading class: /usr/lib64/rados-classes/libcls_rbd.so.1.0.0: Error:
> Could not detect class name.
>

The 1.0.0 is the shared object version number, not really related to
the class version. This should work:

 $ ceph class add -i /usr/lib64/rados-classes/libcls_rbd.so.1.0.0 rbd 1.2 x86-64

We do need to find some better solution for cases where the binaries
are stripped. Currently we avoid stripping all the symbols that have
__cls inside and we encode the class name and version there, e.g.:
0000000000209734 B __cls_name__rbd
0000000000209730 B __cls_ver__1_2

Then we run the cclsinfo script on the binary and it gets the class
name and version out of the shared object, along with the architecture
it was compiled on. We'd like to be able to keep all the different
classes for the different architecture in the same place.
Probably another solution that doesn't require all this hackery will
just hold the class name and version in the shared object filename
and we'll put the shared objects under a subdir per architecture.

Yehuda

Re: rbd create command fails to create image

[Xiaoguang Liu]

Thanks Yehuda,

your command works. I can finally get rbd work on unstable code.



On Mon, Aug 9, 2010 at 11:48 AM, Yehuda Sadeh Weinraub
<yehudasa@gmail.com> wrote:
> On Sun, Aug 8, 2010 at 8:04 PM, Xiaoguang Liu <syslxg@gmail.com> wrote:
>> I tried both ways. none of them worked.
>>
>> BTW, Yehuda said the new class should be v1.2. why I saw 1.0.0 in the
>> error message:
>>
>> Loading class: /usr/lib64/rados-classes/libcls_rbd.so.1.0.0: Error:
>> Could not detect class name.
>>
>
> The 1.0.0 is the shared object version number, not really related to
> the class version. This should work:
>
>  $ ceph class add -i /usr/lib64/rados-classes/libcls_rbd.so.1.0.0 rbd 1.2 x86-64
>
> We do need to find some better solution for cases where the binaries
> are stripped. Currently we avoid stripping all the symbols that have
> __cls inside and we encode the class name and version there, e.g.:
> 0000000000209734 B __cls_name__rbd
> 0000000000209730 B __cls_ver__1_2
>
> Then we run the cclsinfo script on the binary and it gets the class
> name and version out of the shared object, along with the architecture
> it was compiled on. We'd like to be able to keep all the different
> classes for the different architecture in the same place.
> Probably another solution that doesn't require all this hackery will
> just hold the class name and version in the shared object filename
> and we'll put the shared objects under a subdir per architecture.
>
> Yehuda
>
--
To unsubscribe from this list: send the line "unsubscribe ceph-devel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html