[dm-devel] [Lsf-pc] [Topic] Bcache
loke.chetan at gmail.com
Wed Mar 14 18:33:25 UTC 2012
On Wed, Mar 14, 2012 at 2:17 PM, Kent Overstreet <koverstreet at google.com> wrote:
> On Wed, Mar 14, 2012 at 2:12 PM, chetan loke <loke.chetan at gmail.com> wrote:
>> I'm not a dm guru but a quick scan at flash-cache seems like it does
>> what you are saying. Now, if performance isn't acceptable then hashes
>> can be replaced with trees and what-not. Also no one would need to
>> re-invent the stacking mechanism. I saw thin support(atleast
>> documented) for dm. Plus, no matter what cache you come up with you
>> may have to persist/store the meta-data associated with it. And dm
>> seems like the right place to abstract that.
> Bcache kills flash cache on performance - bcache can do around a
> million iops on 4k random reads, and beats it on real world
> applications and hardware too (i.e. mysql).
Don't get too carried away with the perf numbers. re-read what I said:
"if performance isn't acceptable then hashes can be replaced with
trees and what-not".
> I'm not aware of any real features I'm missing out on by not using dm...
But you are not explaining why dm is not the right stack. Just because
it crashed when you tried doesn't mean it's not the right place.
flash-cache works, doesn't it? flash-cache's limitation is because
it's a dm-target or because it is using hashing or something else?
There are start-ups who are doing quite great with SSD-cache+dm. So
please stop kidding yourself.
More information about the dm-devel