On Wed, Mar 14, 2012 at 2:54 PM, Ted Ts'o <tytso@xxxxxxx> 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 -- dm-devel mailing list dm-devel@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/dm-devel
