Re: krbd + format=2 ?

[Laurent Barbe <laurent@ksperis.com>]

Hello Sage,

Thank you for your reply,
I will do like this.

Laurent


Le 05/07/2013 06:12, Sage Weil a écrit :
> On Thu, 4 Jul 2013, Laurent Barbe wrote:
>> Hello,
>>
>> Since I upgrade kernel 3.10-rc6 to 3.10 final, it seems that the format of
>> block device has changed and I can't mount them anymore.
>> I'm using rbd format 2 / xfs.
>>
>> Are you aware of this incompatibility?
>
> Hi Laurent,
>
> There was a problem with earlier -rc's not interoperating with librbd
> because of the object naming.  To recover this image, boot into an -rc6
> kernel, copy the block device out of rbd or into a new image (e.g., rbd
> import /dev/rbd1 newrbd), and then use the new image with 3.10.
>
> Sorry!
> sage
>
>
>
>>
>>
>> SGI XFS with ACLs, security attributes, realtime, large block/inode ug enabled
>> XFS (rbd1): bad magic number
>> ffff880037241000: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  .
>> ffff880037241010: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  .
>> ffff880037241020: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  .
>> ffff880037241030: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  .
>> XFS (rbd1): Internal error xfs_sb_read_verify at line 730 of file t.c. Caller
>> 0xffffffffa0522d95
>>
>> CPU: 0 PID: 182 Comm: kworker/0:1H Not tainted 3.10.0-ccmbg1 #1
>> Hardware name: Dell Computer Corporation PowerEdge 860/0XM089, BIOS
>> Workqueue: xfslogd xfs_buf_iodone_work [xfs]
>>   ffffffff81362b9c 0000000000000071 ffffffffa0524c61 ffffffffa0522d95
>>   00000000000002da 0000000000000000 0000000000000016 ffff88007cbdde00
>>   ffff88003704c800 ffff88007fc1a500 ffffffffa0566222 ffffffffa0522d95
>> Call Trace:
>>   [<ffffffff81362b9c>] ? dump_stack+0xd/0x17
>>   [<ffffffffa0524c61>] ? xfs_corruption_error+0x54/0x6f [xfs]
>>   [<ffffffffa0522d95>] ? xfs_buf_iodone_work+0x3c/0x6a [xfs]
>>   [<ffffffffa0566222>] ? xfs_sb_read_verify+0xa4/0xbf [xfs]
>>   [<ffffffffa0522d95>] ? xfs_buf_iodone_work+0x3c/0x6a [xfs]
>>   [<ffffffffa0522d95>] ? xfs_buf_iodone_work+0x3c/0x6a [xfs]
>>   [<ffffffff81046588>] ? process_one_work+0x191/0x28f
>>   [<ffffffff813650f4>] ? __schedule+0x516/0x51b
>>   [<ffffffff81046a35>] ? worker_thread+0x121/0x1e7
>>   [<ffffffff81046914>] ? rescuer_thread+0x269/0x269
>>   [<ffffffff8104aedd>] ? kthread+0x81/0x89
>>   [<ffffffff8104ae5c>] ? __kthread_parkme+0x5d/0x5d
>>   [<ffffffff8136adec>] ? ret_from_fork+0x7c/0xb0
>>   [<ffffffff8104ae5c>] ? __kthread_parkme+0x5d/0x5d
>> XFS (rbd1): Corruption detected. Unmount and run xfs_repair
>> XFS (rbd1): SB validate failed with error 22.
>>
>> Thanks,
>>
>> Laurent Barbe
>>
>>
>> Le 13/06/2013 05:56, Josh Durgin a ?crit :
>>> 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.
>>>
>>> Josh
>>>
>>> --
>>> 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
>>
>>
--
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