linux-kernel - Bcache version 8

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [day] [month] [year] [list]

Message-ID: <20101005110622.GA2473@moria>
Date:	Tue, 5 Oct 2010 04:06:22 -0700
From:	Kent Overstreet <kent.overstreet@...il.com>
To:	linux-kernel@...r.kernel.org, linux-fsdevel@...r.kernel.org
Subject: Bcache version 8

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(-)
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/