[dm-devel] [Lsf-pc] [Topic] Bcache

[chetan loke]

On Wed, Mar 14, 2012 at 2:54 PM, Ted Ts'o <tytso at mit.edu> wrote:
> On Wed, Mar 14, 2012 at 02:33:25PM -0400, chetan loke wrote:
>> 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.
>
> SATA-attached flash is not the only kind of flash out there you know.
> There is also PCIe-attached flash which is a wee bit faster (where wee
> is defined as multiple orders of magnitude --- SATA-attached SSD's
> typically have thousands of IOPS; Fusion I/O is shipping product today
> with hundreds of thousands of IOPS, and has demonstrated a billion
> IOPS early this year).  And Fusion I/O isn't the only company shipping
> PCIe-attached flash products.
>

We've designed linux targets with million IOPS even before PCIe-flash
came into picture you know. So, I think we do know a thing or two
about million IOPS and performance. when I said 'cache' I used it
loosely. The backing store can be anything - a SSD or PCI-e or
adjacent blade over IB.


> Startups may be doing great on SSD's; you may want to accept the fact
> that there is stuff which is way, way, way better out there than
> SSD's which are available on the market *today*.
>
> And it's not like bache which is a new project.  It's working code,
> just like flash cache is today.  So it's not like it needs to justify
> its existence.
>

we are talking about approaches and not existence.

> Best regards,
>
>                                        - Ted

BR,
Chetan