[Date Prev][Date Next] [Thread Prev][Thread Next]
[Thread Index]
[Date Index]
[Author Index]
Re: [dm-devel] [Lsf-pc] [Topic] Bcache
- From: "Ted Ts'o" <tytso mit edu>
- To: chetan loke <loke chetan gmail com>
- Cc: linux-scsi vger kernel org, Kent Overstreet <koverstreet google com>, dm-devel redhat com, nauman google com, lsf-pc lists linux-foundation org, Vivek Goyal <vgoyal redhat com>
- Subject: Re: [dm-devel] [Lsf-pc] [Topic] Bcache
- Date: Wed, 14 Mar 2012 14:54:56 -0400
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.
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.
Best regards,
- Ted
[Date Prev][Date Next] [Thread Prev][Thread Next]
[Thread Index]
[Date Index]
[Author Index]