All of lore.kernel.org
 help / color / mirror / Atom feed
From: Peter Niemayer <niemayer@isg.de>
To: ceph-devel@vger.kernel.org
Subject: Re: Using other filesystems than btrfs with Ceph
Date: Fri, 11 Jun 2010 18:42:54 +0200	[thread overview]
Message-ID: <hutp2e$od8$1@dough.gmane.org> (raw)
In-Reply-To: <AANLkTin6wleXQVepvMACh8JMr5sa1g4neVXD_Voi7rYT@mail.gmail.com>

On 06/11/2010 06:26 PM, Gregory Farnum wrote:
>> Also, the documentation in the Wiki does not mention what would need
>> to be configured differently if another filesystem was to be used -
>> what would I have to use instead of "btrfs devs = /dev/sdy"?
> You can look at the ceph.conf file produced by the vstart script for a
> non-btrfs example -- just use
> osd data = path
> osd journal = path2
> osd journal size = [# in MB]

Thanks for this info!


> Well, it's possible that you could improve Ceph's performance in
> certain workloads by using different underlying filesystems, but in
> general Ceph's interfaces and protocols are going to matter a lot
> more, and btrfs works very well with it.

It would be interesting to me what would be a factor of slow-down
to be expected when setting up a minimalistic one-node-Ceph service,
where all daemons run on localhost, and just one local filesystem
is created for the OSD, in comparison to using btrfs directly on that
local filesystem?

Would you expect a significant decrease in sequential read/write throughput?
And what about latencies for small reads/writes?

I wonder what would be an acceptable design-goal when ruling
out physical network equipment or cabling for the moment...


Regards,

Peter Niemayer



      parent reply	other threads:[~2010-06-11 16:43 UTC|newest]

Thread overview: 6+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2010-06-11 14:23 Using other filesystems than btrfs with Ceph Peter Niemayer
2010-06-11 16:26 ` Gregory Farnum
2010-06-11 16:40   ` Sage Weil
2010-06-11 16:47     ` Peter Niemayer
2010-06-11 16:54       ` Sage Weil
2010-06-11 16:42   ` Peter Niemayer [this message]

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='hutp2e$od8$1@dough.gmane.org' \
    --to=niemayer@isg.de \
    --cc=ceph-devel@vger.kernel.org \
    /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.