On Wed, Mar 14, 2012 at 2:33 PM, chetan loke <loke.chetan@xxxxxxxxx> wrote: > On Wed, Mar 14, 2012 at 2:17 PM, Kent Overstreet <koverstreet@xxxxxxxxxx> wrote: >> On Wed, Mar 14, 2012 at 2:12 PM, chetan loke <loke.chetan@xxxxxxxxx> 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". Nobody's stopping you. >> 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. If you want me to implement bcache differently, shouldn't you explain why? I'm not sure why I _have_ to justify my decisions to you. -- To unsubscribe from this list: send the line "unsubscribe linux-scsi" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
