All of lore.kernel.org
 help / color / mirror / Atom feed
From: Javen Wu <javen.wu@xtaotech.com>
To: sage@redhat.com
Cc: Peng Xie <peng.hse@xtaotech.com>, ceph-devel@vger.kernel.org
Subject: Is BlueFS an alternative of BlueStore?
Date: Thu, 7 Jan 2016 12:01:55 +0800	[thread overview]
Message-ID: <568DE333.7070206@xtaotech.com> (raw)

Hi Sage,

Sorry to bother you. I am not sure if it is appropriate to send email to 
you
directly, but I cannot find any useful information to address my confusion
from Internet. Hope you can help me.

Occasionally, I heard that you are going to start BlueFS to eliminate the
redudancy between XFS journal and RocksDB WAL. I am a little confused.
Is the Bluefs only to host RocksDB for BlueStore or it's an
alternative of BlueStore?

I am a new comer to CEPH, I am not sure my understanding is correct about
BlueStore. BlueStore in my mind is as below.

              BlueStore
              =========
    RocksDB
+-----------+          +-----------+
|   onode   |          |           |
|    WAL    |          |           |
|   omap    |          |           |
+-----------+          |   bdev    |
|           |          |           |
|   XFS     |          |           |
|           |          |           |
+-----------+          +-----------+

I am curious if BlueFS is able to host RocksDB, actually it's already a
"filesystem" which have to maintain blockmap kind of metadata by its own
WITHOUT the help of RocksDB. When BlueFS is introduced into the picture,
why RocksDB is needed yet? So I guess BlueFS is an alternative of BlueStore
and it's a new ObjectStore without leveraging RocksDB.

Is my understanding correct?

The reason we care the intention and the design target of BlueFS is that 
I had
discussion with my partner Peng.Hse about an idea to introduce a new
ObjectStore using ZFS library. I know CEPH supports ZFS as FileStore 
backend
already, but we had a different immature idea to use libzpool to 
implement a new
ObjectStore for CEPH totally in userspace without SPL and ZOL kernel 
module.
So that we can align CEPH transaction and zfs transaction in order to  
avoid
double write for CEPH journal.
ZFS core part libzpool (DMU, metaslab etc) offers a dnode object store and
it's platform kernel/user independent. Another benefit for the idea is we
can extend our metadata without bothering any DBStore.

Frankly, we are not sure if our idea is realistic so far, but when I 
heard of
BlueFS, I think we need to know the BlueFS design goal.

Thanks
Javen

             reply	other threads:[~2016-01-07  4:08 UTC|newest]

Thread overview: 8+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2016-01-07  4:01 Javen Wu [this message]
2016-01-07 13:19 ` Is BlueFS an alternative of BlueStore? Sage Weil
2016-01-07 14:37   ` peng.hse
2016-01-07 14:40     ` Javen Wu
2016-01-07 15:10       ` Sage Weil
2016-01-07 15:54         ` Javen Wu
2016-01-13 14:31         ` Javen Wu
2016-01-13 14:58           ` Sage Weil

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=568DE333.7070206@xtaotech.com \
    --to=javen.wu@xtaotech.com \
    --cc=ceph-devel@vger.kernel.org \
    --cc=peng.hse@xtaotech.com \
    --cc=sage@redhat.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.