[CentOS] Re: Anaconda doesn't support raid10

Thu May 10 16:12:04 UTC 2007
Ross S. W. Walker <rwalker at medallion.com>

> -----Original Message-----
> From: centos-bounces at centos.org 
> [mailto:centos-bounces at centos.org] On Behalf Of Les Mikesell
> Sent: Thursday, May 10, 2007 9:41 AM
> To: CentOS mailing list
> Subject: Re: [CentOS] Re: Anaconda doesn't support raid10
> 
> Andreas Micklei wrote:
> > Am Donnerstag, 10. Mai 2007 schrieb Feizhou:
> >>> Probably not, but is SATA really much worse then SCSI or 
> SAS?  I did
> >>> some testing on a dell PE 2950 of 750GB SATA's vs SAS and 
> SCSI drives,
> >>> and the SATA drives seem to be faster at least at first 
> glance.  I don't
> >>> have good numbers from the  SCSI tests, but at least for 
> sequantial, I'm
> >>> getting a better speed off the SATAs.
> >> sequential will be better than SCSI due to the packing on 
> those platters
> >> which make up for the lack in rpm. NCQ should even up the 
> random ability
> >> of SATA disks versus SCSI drives but that support has only become
> >> available lately on Linux and you also need the right 
> hardware (besides
> >> the right disks).
> > 
> > SAS and SCSI really has it's place when you need random 
> access with lots of 
> > IOs per second, i.e. Fileserver, Database Server. We 
> upgraded our Fileserver 
> > (NFS, Samba) from SATA SW Raid to SCSI HW Raid and the 
> difference is HUGE. 
> > One the old system a single user doing a large file copy 
> could bring the 
> > system almost to a halt. On the new system you do not even 
> notice if one user 
> > does a similar operation. However plugging one of the same 
> SCSI discs into 
> > your average PC will not give you much advantage.
> > 
> > There is also a line of SATA discs that aim for the low-end 
> server market, the 
> > WD-Raptors. They spin at 10.000 rpm and give much better 
> random access 
> > performance than normal SATA drives. The price point is 
> very attractive 
> > compared to SCSI and SAS. Great alternative for a tight budget.
> > 
> > Here is my favorite site for comparing drives. Has nice 
> background articles 
> > too:
> > http://www.storagereview.com/
> 
> I've always wanted a dollars to dollars comparison instead of 
> comparing 
> single components, and I've always thought that a bunch of RAM could 
> make up for slow disks in a lot of situations.  Has anyone 
> done any sort 
> of tests that would confirm whether a typical user would get better 
> performance from spending that several hundred dollars 
> premium for scsi 
> on additional ram instead?  Obviously this will depend to a certain 
> extend on the applications and how much having additional 
> cache can help 
> it, but unless you are continuously writing new data, most things can 
> live in cache - especially for machines that run continuously.

RAM will never make up for it cause user's are always accessing files
that are just outside of cache in size, especially if you have a lot
of files open and if the disks are slow then cache will starve to
keep up.

Always strive to get the best quality for the dollar even if quality
costs more, because poor performance always makes IT skills look bad.

Better to scale down a project and use quality components then to use
lesser quality components and end up with a solution that can't
perform.

SATA is good for it's size, data-warehousing, document imaging, etc.

SCSI/SAS is good for it's performance, transactional systems, huge
multi-user file access, latency sensitive data.

-Ross

______________________________________________________________________
This e-mail, and any attachments thereto, is intended only for use by
the addressee(s) named herein and may contain legally privileged
and/or confidential information. If you are not the intended recipient
of this e-mail, you are hereby notified that any dissemination,
distribution or copying of this e-mail, and any attachments thereto,
is strictly prohibited. If you have received this e-mail in error,
please immediately notify the sender and permanently delete the
original and any copy or printout thereof.