All of lore.kernel.org
 help / color / mirror / Atom feed
From: Ted Ts'o <tytso@mit.edu>
To: chetan loke <loke.chetan@gmail.com>
Cc: Kent Overstreet <koverstreet@google.com>,
	Vivek Goyal <vgoyal@redhat.com>,
	lsf-pc@lists.linux-foundation.org, nauman@google.com,
	linux-scsi@vger.kernel.org, dm-devel@redhat.com
Subject: Re: [Lsf-pc] [Topic] Bcache
Date: Wed, 14 Mar 2012 14:54:56 -0400	[thread overview]
Message-ID: <20120314185455.GD28042@thunk.org> (raw)
In-Reply-To: <CAAsGZS5UTrYTbncAjk1Vor6R_-KWDboTw3sh+jXCbXm5q_o-TA@mail.gmail.com>

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

  parent reply	other threads:[~2012-03-14 18:54 UTC|newest]

Thread overview: 21+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2012-03-14 13:32 [Topic] Bcache Kent Overstreet
2012-03-14 15:53 ` [Lsf-pc] " Vivek Goyal
2012-03-14 17:24   ` Kent Overstreet
2012-03-14 22:01     ` Bcache Mike Snitzer
2012-03-14 22:09       ` [Lsf-pc] Bcache Williams, Dan J
2012-03-15 17:27       ` Bcache Kent Overstreet
2012-03-15 20:17         ` Bcache Mike Snitzer
2012-03-15 22:59           ` Bcache Kent Overstreet
2012-03-16  1:45             ` Bcache Mike Snitzer
2012-03-15 19:43     ` [Lsf-pc] [Topic] Bcache Vivek Goyal
2012-03-15 23:46       ` Kent Overstreet
2012-03-14 18:12   ` chetan loke
2012-03-14 18:17     ` Kent Overstreet
2012-03-14 18:33       ` chetan loke
2012-03-14 18:41         ` Kent Overstreet
2012-03-14 18:47           ` Christoph Hellwig
2012-03-14 19:04           ` chetan loke
2012-03-15 17:01             ` Kent Overstreet
2012-03-14 18:54         ` Ted Ts'o [this message]
2012-03-14 19:22           ` chetan loke
2012-03-15 17:02           ` Kent Overstreet

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20120314185455.GD28042@thunk.org \
    --to=tytso@mit.edu \
    --cc=dm-devel@redhat.com \
    --cc=koverstreet@google.com \
    --cc=linux-scsi@vger.kernel.org \
    --cc=loke.chetan@gmail.com \
    --cc=lsf-pc@lists.linux-foundation.org \
    --cc=nauman@google.com \
    --cc=vgoyal@redhat.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.