FW: [K12OSN] SATA vs SCSI

[Ken Meyer]

OK, here are two previous messages about RAID hardware that were posted to
the list in a thread about two months ago -- as I suggested: RTFA maybe?  I
know Chris Kacoroski and consider him to be a completely capable and
knowledgeable practitioner who conducts objective, though analyses of the
systems on which his job performance obviously depends.  Chris has presented
to the Greater Seattle Linux Users Group and the Tacoma LUG on several
occasions.

It appears that Chris has identified Seek Systems and EonStor as suppliers
of SATA RAID cards that deal well with those small, random file accesses.
It seems that these folks provide "storage solutions" and maybe not just
controller cards for your own drives, but maybe they work better.  I
recommend that you direct requests for further details to this very helpful
guy.

My role, as I see it, is often to make connections from a position of wide
but not always very deep acquaintance with a host of technologies and
sources, based on a ravenous curiosity maybe overlaid with a touch of ADD.
Contrary to Brian C's opinion, I think that is a valuable service, and not
one that is always covered well by other participants in many environments.

As a bonus, there is mention of the SATA vs. SCSI comparison in the
messages.  The consensus at present seems to be that there is not too much
difference, at least at a common RPM, between these disks for desktop use,
but that SCSI still has a good edge (see comparisons at
www.storagereview.com) for server apps, which may be reduced significantly
when the SATA guys implement effective elevator queuing -- or not.

Sometimes, it is pointed-out that SCSI drives are built more ruggedly, with
better reliably expectations, merely because they are intended for
industrial-strength use.  That may or may not be significant today, when a
manufacturing plant is run by a man and a dog: the man being there to feed
the dog and the dog being there to keep the man from touching anything.

Ken Meyer


----- Message Forwarded -----

From: k12osn-bounces at redhat.com
[mailto:k12osn-bounces at redhat.com]
On Behalf Of Chris Kacoroski
Sent: Monday, September 20, 2004 11:10 AM
To: Support list for opensource software in schools.

Subject: Re: [K12OSN] SATA vs SCSI

Liam,

I did several tests with SATA and SCSI and found out that the controller
card is a limiting factor.  The fundamental difference between the two
technologies is that SCSI drives queue up the requests and the optimize
the path of the r/w head across the disk.  SATA do not have this ability
so the r/w head wanders all over the disk handling the requests in a
first come, first serve basis.

What this means, is that if you are reading or writing one large file,
SATA perform as good as SCSI (if they have the same spindle speed).  If
you have several different processes r/w to multiple files on disk, SCSI
out performs SATA by a large margin.  The new SATA standard out sometime
next year is suppose to include queueing, but until then SCSI is
definitely worth it for small installations like yours.

If you have a large installation (e.g. 2TB+ of disk), you can use a
device like the EonStor raid which connects SATA disks to a scsi
controller and performs very well.  I have one of these and plan to get
another one for a different application.  I tried 3ware cards, but they
failed in my application (I still use them to mirror the system disks
and they work great for that).

cheers,

ski

Liam Marshall wrote:

> this is my current hard drive situation, which will probably have to
> stay until next year.
>
> 1 - small regular ide drive for the system to boot off of.  It holds
>      the /boot partition and does nothing else
>
> 1 - 8 GB ibm SCSI drive, holding /root /usr etc
>
> 1 - 18 HB Seagate SCSI holding  /home /opt and the /swap partition
>
> no raid
>
> In an earlier thread, someone mentioned using SATA drives successfully
> with a large number of users, 25+
>
> When I go to configure next years server (we will upgrade) can I use SATA
> drives in a raid 0 configuration?  I want to increase performance hence
> the raid 0, but heard that SATA drives might not handle a class of 25+
> workstations
>
> any advice?
>
> SATA is cheaper, I assume, than SCSI, so that would be a preferred path
> if true

--
"When we try to pick out anything by itself, we find it
   connected to the entire universe"		John Muir

Chris "Ski" Kacoroski, ckacoroski at nsd.org, 425-489-6263


------------->> Message #2 Forwarded <<-----------------------

Ken Meyer wrote:

> 1) RAID 0 is a very bad deal.  It does not provide very much performance
> increase (apparently in part due to the caching algorithms embedded in the
> typical drive's firmware), AND you have doubled your jeopardy because the
> failure of EITHER drive will eat your lunch (See Comment One below, copied
> from the S/R site untouched by human-driven keyboards).

Agreed.  I only use this for applications that need lots of very fast
tmp disk space.  Most folks use Raid 1 (mirrors).

> 2) The superiority of SCSI, given similar physical characteristics (RPM,
bit
> density, et al) of the drives, has been most evident in servers having
> multi-user, random access to many small files, and that this advantage has
> been due to "elevator queuing" in which the drive actively manages the
order
> of retrieving data.  ATA drives never implemented this feature because the
> advantage in single-user system was small or even negative.  However, SATA
> drives are encroaching on this capability, called TCQ (Tagged Command
> Queuing) by WD and generically, and NCQ (Native...) by Maxtor and Seagate.

SATA should have this in a year or so.

> 3) A question.  It has been my understanding that writing data to, say, a
> RAID 5 array was SLOWER than to a single drive, since space had to be
> allocated for pieces to be put on each of the drives, but that reading
might
> be faster (ATA or SCSI, regardless of TCQ or not).  So, does one get
better
> performance by putting all drives in an independent configuration, maybe
as
> a single volume, than as a RAID array -- reliability and the "redundancy
> tax" aside?

On older arrays, there definitely is a RAID 5 write hit.  On many of the
newer ones (e.g. Seek Systems, EonStor) they get around this by caching
tricks such as immediately writing all data to a temp location on the
raid and then when they get an entire stripe of data, rewriting it
during a pause properly to the Raid5, etc.  I am now using Seek Raid 5
arrays to support enterprise oracle DB as they are a lot cheaper than
mirroring everything (the traditional way).

cheers,

ski