All of lore.kernel.org
 help / color / mirror / Atom feed
* tgt backend driver for Ceph block devices (rbd)
@ 2013-01-17  2:47 Dan Mick
  2013-01-18 16:29 ` FUJITA Tomonori
  0 siblings, 1 reply; 2+ messages in thread
From: Dan Mick @ 2013-01-17  2:47 UTC (permalink / raw)
  To: stgt; +Cc: ceph-devel

Hi, all.  I recently hacked at bs_rdwr and made it work as a 
proof-of-concept driver allowing tgt to be backed by the Ceph[1] storage 
cluster's RADOS block device (rbd)[2].  I thought I'd share the results 
of my investigations, as it's useful even in its current form:

http://github.com/dmick/tgt, forked from http://github.com/fujita/tgt
branch bs_rbd (https://github.com/dmick/tgt/tree/bs_rbd)

This is a simple transliteration of bs_rdwr to use librbd/librados
calls instead of normal file I/O calls (so might be instructive to diff 
bs_rbd.c against bs_rdwr.c to see what was involved).  It currently uses 
only the synchronous librbd interfaces, so each tgtd worker thread will 
block for completion of each request.  See the commit comment
for usage advice.

For those with less exposure to Ceph:

Ceph is a distributed storage system, and rbd provides a block-device 
abstraction to that storage that can be used directly from the kernel or 
from a userland library and things built on it.  That is:

1) you can create rbd images in the cluster, and then expose them as
kernel block devices to machines that talk to the cluster

2) You can create rbd images in the cluster, and then expose them to 
qemu-kvm virtual machines without kernel support (by using 
librbd/librados to access the cluster).

bs_rbd adds another access path: exposing rbd images as iSCSI targets
with strictly-userland code.

I was quite impressed at how easy this was, and how well-organized the 
stgt source is.  Kudos to the developers and maintainers!

--

[1] http://ceph.com, http://ceph.com/docs
[2] http://ceph.com/ceph-storage/block-storage/

^ permalink raw reply	[flat|nested] 2+ messages in thread

* Re: tgt backend driver for Ceph block devices (rbd)
  2013-01-17  2:47 tgt backend driver for Ceph block devices (rbd) Dan Mick
@ 2013-01-18 16:29 ` FUJITA Tomonori
  0 siblings, 0 replies; 2+ messages in thread
From: FUJITA Tomonori @ 2013-01-18 16:29 UTC (permalink / raw)
  To: dan.mick; +Cc: stgt, ceph-devel

On Wed, 16 Jan 2013 18:47:14 -0800
Dan Mick <dan.mick@inktank.com> wrote:

> Hi, all.  I recently hacked at bs_rdwr and made it work as a
> proof-of-concept driver allowing tgt to be backed by the Ceph[1]
> storage cluster's RADOS block device (rbd)[2].  I thought I'd share
> the results of my investigations, as it's useful even in its current
> form:

Sounds interesting. If you send a patch, I'm happy to review and merge
it.

> http://github.com/dmick/tgt, forked from http://github.com/fujita/tgt
> branch bs_rbd (https://github.com/dmick/tgt/tree/bs_rbd)
> 
> This is a simple transliteration of bs_rdwr to use librbd/librados
> calls instead of normal file I/O calls (so might be instructive to
> diff bs_rbd.c against bs_rdwr.c to see what was involved).  It
> currently uses only the synchronous librbd interfaces, so each tgtd
> worker thread will block for completion of each request.  See the

That's fine. I/O worker threads are supposed to handle such
synchronous API (bs_rwdr.c use read/write system calls with O_SYNC).

If rdb provides the async API and it's preferable, then you don't need
to use I/O worker threads like bs_aio.c


> I was quite impressed at how easy this was, and how well-organized the
> stgt source is.  Kudos to the developers and maintainers!

Thanks ;)

^ permalink raw reply	[flat|nested] 2+ messages in thread

end of thread, other threads:[~2013-01-18 16:29 UTC | newest]

Thread overview: 2+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2013-01-17  2:47 tgt backend driver for Ceph block devices (rbd) Dan Mick
2013-01-18 16:29 ` FUJITA Tomonori

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.