From: Martin Fick <mogulguy@yahoo.com>
To: ceph-devel@vger.kernel.org, Alex Elsayed <eternaleye@gmail.com>
Subject: Re: Replacing DRBD use with RBD
Date: Wed, 5 May 2010 13:59:13 -0700 (PDT) [thread overview]
Message-ID: <290088.71767.qm@web36106.mail.mud.yahoo.com> (raw)
In-Reply-To: <hrsibo$29c$1@dough.gmane.org>
--- On Wed, 5/5/10, Alex Elsayed <eternaleye@gmail.com> wrote:
Sorry about the accidental off-list reply, thanks
for replying on list...
> I would recommend benchmarking to have empirical results
> rather than going with my presumptions,
Or my presumptions, :) agreed.
> but in Ceph the metadata servers cache the metadata and
> the OSDs journal writes, so any writes which fit in the
> journal will be quite fast.
Yes, but the kernel will do that also (albeit differently)
for local file systems even if the block device is remote.
> Also, RBD has no way of knowing what reads/writes are
> 'small' in the RBD block device, because it works by splitting
> the disk image into 4MB chunks and deals with those.
Good point. I assume that is tunable, at least by editing
the rbd driver, no?
> This is an advantage in the container virtualization case
> because you can (say) mount the entire Ceph FS on the
> host and treat the containers simply run the containers
> from a very basic LXC or other container config,
> treating the Ceph filesystem as just another directory
> tree from the point of view of the container.
> This simplifies your container config, and gives the
> advantages I named earlier (online resize, etc).
Hmm, while some of those are good advantages (and
some may not be depending on your mindset), I am missing
the main point as the why this is different than with
"real VMs" except for maybe your claim of "not being
usual" ...
> Ceph has POSIX (or as close as possible) semantics,
> matching local filesystems, and provides more features
> than any local FS except BtrFS, which is similarly
> under heavy development.
Perhaps it has many of the features that you want,
but there are many things that many other FSs can
do (good and bad depending again on your mindset),
that ceph cannot and will likely never be able to
do. For example, can it be case insensitive such
as a DOS FS?
> RBD is actually a rather recent addition - the first
> mailing list message about it was on March 7th, 2010,
> whereas Ceph has been in development since 2007.
True, I guess I meant that using the OSDs will likely
always be simpler and more stable than using them
through ceph.
Thanks,
-Martin
next prev parent reply other threads:[~2010-05-05 20:59 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
2010-05-04 23:46 Replacing DRBD use with RBD Martin Fick
2010-05-05 7:30 ` Alex Elsayed
2010-05-05 20:02 ` Alex Elsayed
2010-05-05 20:13 ` Yehuda Sadeh Weinraub
2010-05-05 20:59 ` Martin Fick [this message]
2010-05-05 20:00 ` Yehuda Sadeh Weinraub
-- strict thread matches above, loose matches on Subject: below --
2010-05-05 20:34 Martin Fick
2010-05-06 5:10 ` Thomas Mueller
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=290088.71767.qm@web36106.mail.mud.yahoo.com \
--to=mogulguy@yahoo.com \
--cc=ceph-devel@vger.kernel.org \
--cc=eternaleye@gmail.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox