linux-kernel - Re: [dm-devel] Announcement: STEC EnhanceIO SSD caching software for Linux kernel

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:	Fri, 18 Jan 2013 12:36:42 -0600
From:	Jason Warr <jason@...r.net>
To:	Amit Kale <akale@...c-inc.com>
CC:	device-mapper development <dm-devel@...hat.com>,
	"kent.overstreet@...il.com" <kent.overstreet@...il.com>,
	Mike Snitzer <snitzer@...hat.com>,
	LKML <linux-kernel@...r.kernel.org>,
	"linux-bcache@...r.kernel.org" <linux-bcache@...r.kernel.org>
Subject: Re: [dm-devel] Announcement: STEC EnhanceIO SSD caching software
 for Linux kernel

On 01/18/2013 11:44 AM, Amit Kale wrote:
>> As much as I dislike Oracle that is one of my primary applications.  I
>> > am attempting to get one of my customers to setup an Oracle instance
>> > that is modular in that I can move the storage around to fit a
>> > particular hardware setup and have a consistent benchmark that they use
>> > in the real world to gauge performance.  One of them is a debit card
>> > transaction clearing entity on multi-TB databases so latency REALLY
>> > matters there.  
> I am curious as to how SSD latency matters so much in the overall transaction times.
>
> We do a lot of performance measurements using SQL database benchmarks. Transaction times vary a lot depending on location of data, complexity of the transaction etc. Typically TPM (transactions per minute) is of primary interest for TPC-C.
>

It's not specifically SSD latency.  It's I/O transaction latency that
matters.  This particular application is very sensitive to that because
it is literally someone standing at a POS terminal swiping a
debit/credit card.  You only have a couple of seconds after the PIN is
entered for the transaction to go through your network, application
server to authorize against a DB and back to the POS.

The entire I/O stack on the DB is only a small time-slice of that round
trip.  Your 99th percentile needs to be under 20ms on the DB storage
side.  If your worst case DB I/O goes beyond 300ms it is considered an
outage because the POS transaction fails.  So it obviously takes allot
of planning and optimization work on the DB itself to get good
tablespace layout to even get into the realm where you can have that
predictable of latency with multi-million dollar FC storage frames. 

One of my goals is to be able to offer this level of I/O service on
commodity hardware.  Simplify the scope of hardware, reduce the number
of points of failure, make the systems more portable, reduce or
eliminate dependence on any specific vendor below the application and
save money.  Not to mention reduce the number of fingers that can point
away from themselves saying it is someone elses problem to find fault.

Allot of the pieces are already out there.  A good block caching target
is one of the missing pieces to help fill the ever growing canyon
between non-block device system performance and storage.  What they have
done with L2ARC and SLOG in ZFS/Solaris is good but it has some serious
short comings in other areas that DM/MD/LVM do extremely well.

I appreciate all of the brilliant work all of you guys do and hopefully
I can contribute a little bit of usefulness to this effort.

Thank you,

Jason
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/