Re: [Lsf-pc] [Topic] Bcache

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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.

dm-devel mailing list

[DM Crypt]     [Fedora Desktop]     [ATA RAID]     [Fedora Marketing]     [Fedora Packaging]     [Fedora SELinux]     [Yosemite Discussion]     [Yosemite Photos]     [KDE Users]     [Fedora Tools]     [Fedora Docs]

Add to Google Powered by Linux