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". > 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. -- 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
