On 06/12/2013 10:56 PM, Josh Durgin wrote: > On 06/11/2013 09:59 PM, Chris Dunlop wrote: >> On Sat, Jun 08, 2013 at 12:48:52PM +1000, Chris Dunlop wrote: >>> On Fri, Jun 07, 2013 at 11:54:20AM -0500, Alex Elder wrote: >>>> On 06/03/2013 04:24 AM, Chris Dunlop wrote: >>>>> I pulled the for-linus branch (@ 3abef3b) on top of 3.10.0-rc4, and >>>>> it's >>>>> letting me map a format=2 image (created under bobtail), however >>>>> reading >>>>> from the block device returns zeros rather than the data. The same >>>>> image >>>>> correctly shows data (NTFS filesystem) when mounted into kvm using >>>>> librbd. >>>> >>>> Have you tried using a format 2 image that you created using >>>> the Linux rbd environment? It would be good to know whether >>>> that works for you. >>> >>> Sorry, how to you mean "created using the Linux rbd environment"? >>> The one I was trying was created using: >>> >>> rbd create --format 2 xxx --size nnnnn >>> >>> ...then populated using qemu/librbd. >> >> Looks like the kernel rbd and librbd aren't compatible, as at >> 3.10.0-rc4+ceph-client/for-linus@3abef3b vs librbd1 0.56.6-1~bpo70+1. > > Thanks for the detailed report Chris. The kernel client was using the > wrong object names for format 2 (zero-padding them with a different > length than librbd). I just posted a patch fixing this. I remember talking about this Josh. I had suggested we use a longer one so the full range of values would be represented by the default name, and as I recall you said it had already been done on the user space side. I'm sorry if no bug got opened to be sure that got resolved... -Alex > Josh > -- 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
