All of lore.kernel.org
 help / color / mirror / Atom feed
From: Josh Durgin <josh.durgin@inktank.com>
To: Sage Weil <sage@inktank.com>
Cc: ceph-devel@vger.kernel.org
Subject: Re: v0.47 released
Date: Mon, 21 May 2012 00:37:10 -0700	[thread overview]
Message-ID: <4FB9F0A6.7040808@inktank.com> (raw)
In-Reply-To: <Pine.LNX.4.64.1205202137430.843@cobra.newdream.net>

On 05/20/2012 09:38 PM, Sage Weil wrote:
> It's been another three weeks and v0.47 is ready.  The highlights include:
>
>   * librbd: write-thru cache mode

Some more detail on rbd caching:

By default librbd does no caching - writes and reads go directly to the
storage cluster, and writes return only when the data is on disk on all
replicas.

With caching enabled, writes return immediately, unless there are more
than rbd_cache_max_dirty unflushed bytes. In this case, the write
triggers writeback and blocks until enough bytes are flushed.

To enable writethrough mode, set rbd_cache_max_dirty to 0. This means
writes return only when the data is on disk on all replicas, but reads
may come from the cache.

The cache is in memory on the client, and each rbd image has its own.
Since it's local to the client, and there's no coherency if there are
others accessing the image, running something like GFS or OCFS on top
of rbd would not work with caching enabled.

The options for controlling the cache are:

option                 | type      | default | description
-----------------------+-----------+---------+------------
rbd_cache              | bool      | false   | whether caching is enabled
rbd_cache_size         | long long | 32 MiB  | total cache size in bytes
rbd_cache_max_dirty    | long long | 24 MiB  | maximum number of dirty 
bytes before triggering writeback
rbd_cache_target_dirty | long long | 16 MiB  | writeback starts at this 
threshold, but does not block the write
rbd_cache_max_age      | float     | 1.0     | seconds in cache before 
writeback starts

The cache code was written for ceph-fuse a few years ago, so it's been
in use for a while now. It was just tweaked a bit to allow librbd
to use it. The rbd_cache_* options have the same meanings as the
client_oc_* options for ceph-fuse.

>   * librbd: improved error handling

To clarify, these were fixes for error handling in the caching module
used by ceph-fuse and librbd, and does not matter if you aren't using
ceph-fuse or rbd caching. It made write errors be returned to the
caller when the cache is flushed, and exposed read errors to the client
as well.

0.47 also includes a fix for a deadlock that was more likely to 
triggered with rbd caching enabled. I don't know of any outstanding 
issues with rbd caching since that was fixed.

Josh

      parent reply	other threads:[~2012-05-21  7:37 UTC|newest]

Thread overview: 4+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2012-05-21  4:38 v0.47 released Sage Weil
2012-05-21  4:43 ` Sage Weil
2012-05-21  6:46 ` Stefan Priebe - Profihost AG
2012-05-21  7:37 ` Josh Durgin [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=4FB9F0A6.7040808@inktank.com \
    --to=josh.durgin@inktank.com \
    --cc=ceph-devel@vger.kernel.org \
    --cc=sage@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.