[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20130116012914.GA27245@agk-dp.fab.redhat.com>
Date: Wed, 16 Jan 2013 01:29:15 +0000
From: Alasdair G Kergon <agk@...hat.com>
To: Kent Overstreet <koverstreet@...gle.com>
Cc: James Bottomley <James.Bottomley@...senPartnership.com>,
linux-kernel@...r.kernel.org, linux-bcache@...r.kernel.org,
akpm@...ux-foundation.org, tj@...nel.org, axboe@...nel.dk,
snitzer@...hat.com, agk@...hat.com, neilb@...e.de
Subject: Re: Bcache v. whatever
On Tue, Jan 15, 2013 at 03:33:47PM -0800, Kent Overstreet wrote:
> I haven't been active on dm-devel, besides the occasional cross
> posting... not sure what activity you're referring to on the dm list,
A caching framework based on dm has been proposed by Joe Thornber (the
original author of dm).
Mike Snitzer is trying to adapt the performance tests for this dm-based
framework to include the latest bcache code that you just posted to
start to give us an idea of the circumstances in which each of them work
well (or badly).
1, Caching is a complicated feature: It's easy to get no benefit or even
a negative benefit from a cache if you use an inappropriate policy or
don't tune it to your I/O patterns.
2. We now have several independent/overlapping implementations of this
type of caching. Comparing and contrasting them should help us to tease
out the critical design elements and optimisations and decide which of
them together or separately (or some hybrid) would enable the kernel to
support the widest range of situations users require with the minimum
of code and complexity.
3. We all want to move quickly now, perhaps even with something in the
next merge window if we can or otherwise the one after that.
Alasdair
--
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/
Powered by blists - more mailing lists