From: Chris Dunlop <chris@onthe.net.au>
To: Alex Elder <elder@inktank.com>
Cc: ceph-devel@vger.kernel.org
Subject: Re: krbd + format=2 ?
Date: Wed, 12 Jun 2013 14:59:49 +1000 [thread overview]
Message-ID: <20130612045949.GA13654@onthe.net.au> (raw)
In-Reply-To: <20130608024852.GA31065@onthe.net.au>
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.
I can create a format=2 rbd image, map it, format and populate it using the
mapped device. I can then see that data after unmounting unmapping, then
re-mapping and re-mounting. However if I then attach that image via librbd to a
qemu-1.5.0~rc3 vm using the invocation below, the vm sees the whole device as
zeros.
Likewise, if I create a new format=2 rbd image, attach it via librbd to a
qemu-1.5.0~rc3 vm, format it and populate it, that data is thereafter visible
in the vm (e.g. after remounting etc.). But if I map that image using the
kernel client, again I get a device full of zeros.
# dpkg -l \*ceph\* \*rbd\* \*rados\* | grep ^i
ii ceph 0.56.6-1~bpo70+1 amd64 distributed storage and file system
ii ceph-common 0.56.6-1~bpo70+1 amd64 common utilities to mount and interact with a ceph storage cluster
ii librados2 0.56.6-1~bpo70+1 amd64 RADOS distributed object store client library
ii librbd1 0.56.6-1~bpo70+1 amd64 RADOS block device client library
##
## Attach disk to vm
##
# virsh attach-device test <(cat <<END
<disk type='network' device='disk'>
<driver name='qemu' type='raw'/>
<auth username='vm'>
<secret type='ceph' uuid='xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx'/>
</auth>
<source protocol='rbd' name='rbd/crd-test'/>
<target dev='vdc' bus='virtio'/>
<address type='pci' domain='0x0000' bus='0x00' slot='0x7' function='0x0'/>
</disk>
END
)
Cheers,
Chris
next prev parent reply other threads:[~2013-06-12 4:59 UTC|newest]
Thread overview: 10+ messages / expand[flat|nested] mbox.gz Atom feed top
2013-06-03 9:24 krbd + format=2 ? Chris Dunlop
2013-06-07 16:54 ` Alex Elder
2013-06-08 2:48 ` Chris Dunlop
2013-06-12 4:59 ` Chris Dunlop [this message]
2013-06-13 3:56 ` Josh Durgin
2013-06-13 6:35 ` Chris Dunlop
2013-06-15 17:01 ` Alex Elder
2013-07-04 14:45 ` Laurent Barbe
2013-07-05 4:12 ` Sage Weil
2013-07-05 7:39 ` Laurent Barbe
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20130612045949.GA13654@onthe.net.au \
--to=chris@onthe.net.au \
--cc=ceph-devel@vger.kernel.org \
--cc=elder@inktank.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.