linux-fsdevel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Kent Overstreet <kent.overstreet@gmail.com>
To: linux-kernel@vger.kernel.org, linux-fsdevel@vger.kernel.org
Subject: Bcache version 8
Date: Tue, 5 Oct 2010 04:06:22 -0700	[thread overview]
Message-ID: <20101005110622.GA2473@moria> (raw)

Bcache is a patch to cache arbitrary block devices with an SSD. It's got
writeback caching, it uses a hybrid btree/log for the index, and it's
designed around avoiding random writes. It's fast, on benchmarks that
test random IO it's faster than just using the SSD (with my corsair
nova) - at least with bonnie++ and sysbench's mysql benchmark.

It should be about beta quality now - provided you've got backups (this
is highly complicated code that handles your data, after all) you should
be able to use it on non critical machines. It needs more testers
though, proceed with caution until you've tested it on your own setup.
Patch is currently against 2.6.35, alas I need to backport before I can
go back to targeting mainline.

There are some important caveats, the main one being that the ordering
constraints of barriers are are ignored - worse, silently (due to the
way it hooks into existing block devices instead of providing its own).
You must explicitly disable barriers when you mount your filesystem if
you don't want filesystem corruption after you reboot (writes are never
returned as completed before everything's on disk though - it doesn't
act like a disk that caches writes, it's just the ordering that's
problematic).

Besides that, IO error handling is working, and recovering from unclean
shutdown appears to be working reliably - there's one race that I know
of left so it shouldn't be trusted, but in practice it's very hard to
hit. I've been kill -9ing VMs while they're running dbench/bonnie/etc.
and not finding any errors.

Biggest thing left is making memory allocation deadlock proof - in
particular for the btree, which I'm currently using the page cache for.
The current code works, but I doubt it's entirely correct or sane - if
any reviewers would be willing to take a look at what I'm trying to do
there, that's probably what needs it most.

Also, anyone have any opinion on whether I should inline a 6k line
patch? Given that there's not much I can do to usefully break it up, I
don't know that it'd help - suggestions are welcome.

Git repo is up at:
git://evilpiepirate.org/~kent/linux-bcache.git
Wiki is up at http://bcache.evilpiepirate.org

 Documentation/bcache.txt |   75 +
 block/Kconfig            |   14 +
 block/Makefile           |    4 +
 block/bcache.c           | 5279 ++++++++++++++++++++++++++++++++++++++++++++++
 block/bcache_util.c      |  140 ++
 block/bcache_util.h      |  297 +++
 block/blk-core.c         |   10 +-
 fs/bio.c                 |   17 +-
 include/linux/bio.h      |    4 +
 include/linux/blkdev.h   |    2 +
 include/linux/fs.h       |    5 +
 include/linux/sched.h    |    4 +
 kernel/fork.c            |    3 +
13 files changed, 5850 insertions(+), 4 deletions(-)

                 reply	other threads:[~2010-10-05 11:06 UTC|newest]

Thread overview: [no followups] expand[flat|nested]  mbox.gz  Atom feed

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=20101005110622.GA2473@moria \
    --to=kent.overstreet@gmail.com \
    --cc=linux-fsdevel@vger.kernel.org \
    --cc=linux-kernel@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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).