[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

RE: NT and Linux



> -----Original Message-----
> From: King Lee [mailto:king@ultrix6.cs.csubak.edu]
> Sent: Wednesday, May 27, 1998 12:29 PM
> To: debian-user@lists.debian.org
> Cc: recipient list not shown; @lists.debian.org@artecon
> Subject: NT and Linux
> 
> 
> 
> Hello,
> 
> I got into a discussion with a system administrator of
> a website.  The system administrator wishes  to use
> NT because it supports software raid 5 (raid without
> a special controller). I thought if it works, 
> there  would be a terrible performance
> degradation. The system administrator said only 
> if a disk goes down would there be a performance hit.

There will be some performance loss, since the system CPU will need to
handle the RAID algorithm.  Software RAID also means buying the SW to
support it or having it come with the system (as it does with NT).  It
is still necessary to purchase the disk "farm" and perhaps more HBA's
to distribute the load and improve redundancy.  There are no
restrictions
that I know of about the interface or disk types used.

One issue is how much I/O is written at a time and the size of
the "stripes" of data written to each disk.  As an example a 5 disk
array using a stripe size of 16K will have a big performance hit
(whether implemented in SW or HW) if a write of less than 4*16K (64K)
is made.  The RAID "system" must then read the unchanged data from
the disks, make the needed changes, calculate the new parity and
write the whole thing back.  This takes CPU cycles and will affect
system performance at some load levels.  And even if the writes are
full stripes, it still needs to calculate the parity and write the
stripes to disk.

Another issue is the type of I/O being done (random vs. sequential)
but this impacts I/O performance in either SW or HW RAID.  The more
random the I/O, the beter the chances are that several writes (or
reads) will land on different disks in the array, reducing seek time
issues.  I/O performance will also improve as more "threads" are run.

> Does anyone here know anything about
> The questions I have are 
> 
>    1.   Has anyone here had any experience or knowledge
> 	about software raid. How good is it?

I have used it, but not recently and not in a production environment.
It does/did work.  (I'm a test engineer so I beat the hell out of it.
I had no failures or problems.)

>    2.   Does Linux  support hardware raid 5

Basically, any system can "support" hardware RAID at any level, since
the RAID functions are handled by the RAID controller.  But then there
needs to be some way to configure the RAID subsystem.  This can be done
by either a serial interface to the RAID subsystem controller, using a
terminal emulator, or by special software using a SCSI pass through
to send information to the controller over the SCSI bus.  This assumes
a SCSI subsystem of course.  The subsystem manufacturers are building
"high" performance systems, so the dollar outlay can be large (4 or 9
GB 7200 RPM Ultra SCSI disks in a cabinet running Ultra SCSI to the
host, supporting a "large" number of drives (7 or more)).

The serial method is fast and easy but does not scale well to large
numbers of systems, where the SCSI base scales nicely but is more
difficult to implement well.

> 
> I think this guy is looking for an excuse not to use
> Linux.
> 
> King Lee
> 
> 
> 
> --
> To UNSUBSCRIBE, email to debian-user-request@lists.debian.org
> with a subject of "unsubscribe". Trouble? Contact 
> listmaster@lists.debian.org
> 


--
To UNSUBSCRIBE, email to debian-user-request@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org


Reply to: