On Tue, Nov 10, 2009 at 3:35 PM, Martin K. Petersen
[off-list ref] wrote:

quoted

quoted

quoted

quoted

quoted

"Chris" == Chris Worley [off-list ref] writes:

Chris> I'm not saying the SCSI protocol is bad, I'm saying the
Chris> SAS/SATA/SCSI controllers, that have been optimized for years for
Chris> rotating media, don't have the compute power to handle the sort
Chris> of performance attainable with SSS.

And I'm saying that at least in the SCSI case that's untrue.  SAS and FC
controllers are optimized for lots and lots of I/O because their main
application is driving large storage arrays which have performance
comparable to the solid state devices you mention.

We're going to have to agree to disagree on this.  My feeling is, you
haven't tried the next generation in I/O performance, only the slow
SSD's currently available, and don't (yet) see the potential for
getting rid of all the hardware layers that evolved around rotating
media.  And when you talk of FC... there's more performance
inhibition.  Slow hardware like 10G Ethernet and FC8 can't keep up
with the performance required for fast SSS I/O.  A single QDR IB port
is a good start, with 3GB/s per port (measured using SRP to export the
drives).  How many FC8 or 10G over iSCSI ports would it take to get
one QDR IB ports performance(?)... then start thinking 2x, 4x, 8x, ...
and the complexity of the old hardware becomes daunting when trying to
scale.   Again, to scale easily and with less complexity: you need
your fundamental components to be fast.  SSD's, FC, 10G are last
generation hardware and way too slow.

You can use a 90's vintage distributed supercomputer with 100's of
processors to run tasks that one CPU can do as fast or faster today...
but many would agree that the new CPU is probably an easier choice.

And again, I'm not attacking the SCSI protocol, just the controller
performance; but getting rid of unnecessary OS software layers (i.e.
when you can directly use a block device), also provides more
performance.  When you've got <50usecs latency storage, every CPU
cycle counts.

<snip>

Chris> I'd run IOZone and fill the drive (as I recall ~200GB) w/ files
Chris> and benchmark, which, at the end, IOZone would delete all the
Chris> files created (in the hundreds), and the delete/discard process
Chris> was no more time consuming than just the delete process (for
Chris> everything on the drive).  This was w/ the original 2.6.27 and
Chris> 2.6.28 ext4 "discard" implementations.

And which device was this?  How did it implement discard?

This was a non-GPL driver (as is the management layer for all SSD's),
so I doubt you're interested.

The methodology used was that laid out by David Wodhouse in:

http://lwn.net/Articles/293658/

Basically: 1) register for the discard, 2) decode the write BIO's that
indicate "discard", 3) send completion when done.

Chris

--
Martin K. Petersen      Oracle Linux Engineering

--
To unsubscribe from this list: send the line "unsubscribe linux-raid" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html