Faster? Raid 1+0 or Raid 5

Faster? Raid 1+0 or Raid 5

Post by Tekn » Wed, 04 Jun 2003 23:09:31



All else being equal which would provide faster IO.  4x73GB drives in Raid
1+0 or 4x73GB drives in RAID 5?  The use would be High IO like a SQL DB or
log.

Thanks

 
 
 

Faster? Raid 1+0 or Raid 5

Post by Jeff Kenned » Wed, 04 Jun 2003 23:29:34


All else being equal, it depends on your access pattern.  Reads or
writes?

If this is primarily a read database then raid 5 would be better since
you have more spindles to access and no parity to calculate.

If primarily write or mixed, go with 1+0.

Of course, all of the above depends on the type of storage you're
using but it's a good yardstick at least.

~JK



Quote:>All else being equal which would provide faster IO.  4x73GB drives in Raid
>1+0 or 4x73GB drives in RAID 5?  The use would be High IO like a SQL DB or
>log.

>Thanks


 
 
 

Faster? Raid 1+0 or Raid 5

Post by Aleksey Bienema » Thu, 05 Jun 2003 02:51:20


Generaly, RAID 5 is slower than RAID1+0 due to slow writes:

http://www.pcguide.com/ref/hdd/perf/raid/levels/singleLevel5-c.html

However, that would be comparing configuration with equal amount of usable
space: 4 drives in RAID5 vs. 6 drives in RAID1+0 or 4 drives in RAID5
against 3 drives in RAID 5.  I do not know how 4 RAID 5 compares to 4 RAID
1+0

Aleksey

P.S. antipork: second ab is protegepartners


Quote:> All else being equal which would provide faster IO.  4x73GB drives in Raid
> 1+0 or 4x73GB drives in RAID 5?  The use would be High IO like a SQL DB or
> log.

> Thanks

 
 
 

Faster? Raid 1+0 or Raid 5

Post by xx » Sat, 14 Jun 2003 01:31:27



> All else being equal which would provide faster IO.  4x73GB drives in Raid
> 1+0 or 4x73GB drives in RAID 5?  The use would be High IO like a SQL DB or
> log.

Is the RAID system software based or hardware based? i.e. do you have a
dedicated RAID controller or is it done using system software drivers?

1+0 RAID is pretty slow in that it requires double the amount of data to
be written to the disks, however, this can be done in parallel, so its
not so bad.

RAID 5 performs better than RAID 3 as the parity is distributed across
multiple disks, but is usually slower than stripe/mirror because of
parity calculation.

Both systems are faster to read than they are to write. Both systems
have a good amount of recovery. 1+0 is better in the it can lose a
number of disks (as long as no two mirrored disks are lost). RAID 5 can
only lose one disk before data loss.

If this is a software RAID system, managed by system level drivers, I
would stay away from RAID 5 as there is a CPU overhead to manage the
parity, thus I would use stripe/mirror, but you would only get 146G.

If this is a stand-alone hardware RAID, the parity calculations and data
organization are handled via an external CPU, so there will be no cost
associated with it. I would go RAID 5 here because you would get 219G
and performance would probably be identical.

Also, one last thing, depending on your application, the RAID technology
comes in to play. A software RAID system using multiple disks, each on
their own SCSI controller, may have a better I/O performance than a
dedicated hardware RAID, as each disk can send data to the controller
simultaneously.

I could go on, but suffice to say, it isn't a question of "which is
faster," it is a question of "which is faster in my application?" Which
is a different and much more involved question.

 
 
 

Faster? Raid 1+0 or Raid 5

Post by Thoma » Sat, 14 Jun 2003 07:32:04



> Is the RAID system software based or hardware based? i.e. do you have a
> dedicated RAID controller or is it done using system software drivers?

Both have good and bad implementations...

Quote:> 1+0 RAID is pretty slow in that it requires double the amount of data to
> be written to the disks, however, this can be done in parallel, so its
> not so bad.

There is absolutely no need for mirroring to be slower than writing to a single
disk. For reading it is definitely faster: you get 2 disks to read from.

Quote:> RAID 5 performs better than RAID 3 as the parity is distributed across
> multiple disks, but is usually slower than stripe/mirror because of
> parity calculation.

Not so much from the parity calculation itself, but because to write 1 block one
needs to read that block, then write it, calculate parity on the difference,
then read the parity block, xor with parity, and write back. In the meantime
that block on the other disks in the stripe must be locked...

The alternative is to aggressively cache written data and hope you can assemble
a full stripe width of data, on which you can calculate parity without reading
anything back from disk, and writing everything in one go.

Quote:> Also, one last thing, depending on your application, the RAID technology
> comes in to play. A software RAID system using multiple disks, each on
> their own SCSI controller, may have a better I/O performance than a
> dedicated hardware RAID, as each disk can send data to the controller
> simultaneously.

I've seen a lot of seriously slow RAIDs. Both software and hardware (lots of
internal controller cards are slow). Linux software raid is extremely fast, but
does full resyncs after unclean shutdown and can't continue an interrupted
rebuild, but will start over.

Quote:> I could go on, but suffice to say, it isn't a question of "which is
> faster," it is a question of "which is faster in my application?" Which
> is a different and much more involved question.

True. First check whether write performance is an issue at all, given the number
of disks and so on.

Thomas

 
 
 

Faster? Raid 1+0 or Raid 5

Post by Bill Tod » Sat, 14 Jun 2003 08:26:43




> > Is the RAID system software based or hardware based? i.e. do you have a
> > dedicated RAID controller or is it done using system software drivers?

> Both have good and bad implementations...

> > 1+0 RAID is pretty slow in that it requires double the amount of data to
> > be written to the disks, however, this can be done in parallel, so its
> > not so bad.

> There is absolutely no need for mirroring to be slower than writing to a
single
> disk.

There is unless the spindles are synchronized (as in some RAID-3
implementations) - and that would kill your read performance (since the two
disks couldn't service reads independently):  without synchronized spindles,
instead of waiting an average amount of time for one disk's head to attain
the necessary position you have to wait a slightly longer average amount of
time for the worse-positioned of the two disks' heads to attain the
necessary position.

But small, random RAID-1 writes tend to be *considerably* faster (with much
less effect on overall throughput) than RAID-5 writes (though large writes
that can be placed on the disks in full 'stripes' may actually be a bit
faster and more efficient with RAID-5).

Quote:> For reading it is definitely faster: you get 2 disks to read from.

But that helps only if the implementation takes advantage of that fact.  And
how much it helps is access-pattern-dependent:  it won't necessarily help
much at all for random patterns, since the accesses will tend to spread
themselves fairly naturally across the disk set anyway.

It does give you potentially twice the streaming bandwidth for a *single*
large read operation, but even there you trade off a bit of overall
throughput because of the overhead of doing two seeks (one for each disk)
rather than just one - and you can obtain equal throughput from a RAID-5
array simply by using a small enough per-disk stripe size to allow the
application to read from as many disks at once as is necessary..

The bottom line is that for read activity the number of disks in service is
the * factor in determining throughput, regardless of whether they're
arranged in a RAID-1 or RAID-5 configuration (at least until a disk fails:
at that point, RAID-5 throughput is halved, whereas RAID-1 average
throughput is cut by only 1/Nth).  There's not too much difference in
response time either:  while going to the better-positioned disk might give
measurably better response time in a lightly-loaded system, it's
questionable whether saving the occasional couple of milliseconds every once
in a while would be noticeable.

Quote:

> > RAID 5 performs better than RAID 3 as the parity is distributed across
> > multiple disks, but is usually slower than stripe/mirror because of
> > parity calculation.

> Not so much from the parity calculation itself, but because to write 1
block one
> needs to read that block, then write it, calculate parity on the
difference,
> then read the parity block, xor with parity, and write back.

Well, both reads can be done in parallel (if they need to be done at all:
one or both may still be in the disk's or controller's cache) and so can
both writes - but on average it still tends to be considerably slower than a
RAID-1 write.

 In the meantime

Quote:> that block on the other disks in the stripe must be locked...

Certainly not against reads.  And it's not clear why they'd have to be
locked against writes either:  if the controller has NVRAM it can easily
keep track of multiple concurrent updates to the same stripe safely, and if
not then it's kind of a *shoot anyway (since there's no way to make the
update of even a single data segment atomic with the update of the
associated parity segment:  all that you can do on restart is ensure that
they're consistent with each other, even though the result may be garbage
from a higher-level viewpoint).

Quote:

> The alternative is to aggressively cache written data and hope you can
assemble
> a full stripe width of data, on which you can calculate parity without
reading
> anything back from disk, and writing everything in one go.

Which of course is safe only with NVRAM to cache in (and even then may not
be *really* safe unless the NVRAM itself is mirrored).

Quote:

> > Also, one last thing, depending on your application, the RAID technology
> > comes in to play. A software RAID system using multiple disks, each on
> > their own SCSI controller, may have a better I/O performance than a
> > dedicated hardware RAID, as each disk can send data to the controller
> > simultaneously.

> I've seen a lot of seriously slow RAIDs. Both software and hardware (lots
of
> internal controller cards are slow). Linux software raid is extremely
fast, but
> does full resyncs after unclean shutdown and can't continue an interrupted
> rebuild, but will start over.

Again, a consequence of the lack of associated NVRAM.  Of course, it could
at least allow continuation after an interrupted rebuild using fairly
minimal checkpointing mechanisms, and could avoid the need for complete
resyncs by use of a log (though this would slow normal operations down
noticeably unless significantly integrated with other improvements).

- bill

 
 
 

Faster? Raid 1+0 or Raid 5

Post by Scott Howar » Sat, 14 Jun 2003 23:44:06



Quote:>> Is the RAID system software based or hardware based? i.e. do you have a
>> dedicated RAID controller or is it done using system software drivers?

> Both have good and bad implementations...

I've yet to see a good software RAID-5 implementation, and I'd argue that
such a thing can't exist based on the fact that RIAD-5 really needs to
use some form of non-volatile write caching to work well, and you can't
do that in software.

Quote:>> 1+0 RAID is pretty slow in that it requires double the amount of data to
>> be written to the disks, however, this can be done in parallel, so its
>> not so bad.

> There is absolutely no need for mirroring to be slower than writing to a single

Not so.  Presuming software mirroring it will definitely be slower - for
a number of reasons.
The first is simply the additional CPU cycles needed to write the data
to disk twice. Depending on a number of factors this will range from small
to very small, but it will always be greater than a single write.

The second reason is that the response times for the two disks will not be
the same, so the time it takes one copy of the data to hit the disk will
normally be longer than the time for the other to hit the other disk.
The exact impact this will have depends on the implementation, but a
"safe" implementation will normally wait until the data had made it to
both disks until it ack's the write to the higher levels (eg, the app),
so the write time will end up being the maximum of the time to write to
each disk - which will be greater than the time to write to a single disk.

That said, there are some edge cases where writes with mirroring can be
faster than without. eg, as reads in a mirror will normally be spread across
both disks, the nett result is that for reads the disks will generally be
less busy than they would be if it wasn't mirrored. Being less busy means
that in a busy mixed read/write environment writes can frequently complete
faster than they would have in a non-mirror setup, simply due to less spindle
contention occuring.

  Scott

 
 
 

Faster? Raid 1+0 or Raid 5

Post by Net Worke » Sun, 15 Jun 2003 00:44:25


Any comments on  NetApps RAID 4 implementation ?
 
 
 

Faster? Raid 1+0 or Raid 5

Post by Bill Tod » Sun, 15 Jun 2003 04:21:58



...

Quote:> I've yet to see a good software RAID-5 implementation, and I'd argue that
> such a thing can't exist based on the fact that RIAD-5 really needs to
> use some form of non-volatile write caching to work well, and you can't
> do that in software.

Sure you can:  use a circular log (replicated on two of the disks in the
array - it only needs to be a few MB in size) to guarantee consistency, much
as anyone who cared about integrity would do for any write-back cache.
Small writes just get dumped into the log (with latency comparable to that
for RAID-1) for later write-back (when you'll at least have the opportunity
to optimize the order of disk requests to minimize seek time and at best can
consolidate them into a full-stripe write); writes large enough to span a
full stripe can be written back directly (with a notation in the log
indicating the activity in case it's interrupted in the middle, though while
this will guarantee internal consistency between data and parity without the
need for a full-array reconstruction it won't make the large write atomic
from the application's viewpoint).  If most of your write activity is lazy
anyway (from the viewpoint of the system cache driving it), the occasional
added latency (compared to what you'd have using NVRAM instead of a log -
and as I noted before that may not be quite as reliable unless the NVRAM is
itself mirrored) won't even be noticeable.

- bill

 
 
 

Faster? Raid 1+0 or Raid 5

Post by Charles Shannon Hendr » Tue, 17 Jun 2003 11:20:19




> Generaly, RAID 5 is slower than RAID1+0 due to slow writes:

> http://www.pcguide.com/ref/hdd/perf/raid/levels/singleLevel5-c.html

Wouldn't the write penalty be a little less though, if you have plenty
of bandwidth on your controller and/or you are using hardware raid that
takes the raid5 traffic off the SCSI bus?

--

-----= Posted via Newsfeeds.Com, Uncensored Usenet News =-----
http://www.newsfeeds.com - The #1 Newsgroup Service in the World!
-----==  Over 80,000 Newsgroups - 16 Different Servers! =-----

 
 
 

Faster? Raid 1+0 or Raid 5

Post by Jeff Kenned » Wed, 18 Jun 2003 06:44:02


It's good.  What do you want to know about it?

It allows you to easily expand an existing volume.  The parity drive
can be a bottleneck but their cache and file system alleviate most of
that.  Since it's a specific-funtion appliance it's optimized for that
funtion, so even though it's still software raid the overhead is much,
much less noticeable than say a Sun box running VxVM in raid 5.  In
fact, I can't honestly say I've ever had a performance problem that
was attributable to the raid.  For the most part, it screams.

~JK



Quote:>Any comments on  NetApps RAID 4 implementation ?

 
 
 

Faster? Raid 1+0 or Raid 5

Post by Thoma » Thu, 19 Jun 2003 04:51:18



>>Generaly, RAID 5 is slower than RAID1+0 due to slow writes:
> Wouldn't the write penalty be a little less though, if you have plenty
> of bandwidth on your controller and/or you are using hardware raid that
> takes the raid5 traffic off the SCSI bus?

There is a difference between synchronous and asynchronous writes.

But, for synchronous, in the worst case you need to wait for 2 transactions:

1 - read old data and old parity simultaneously

no I/O - xor old data with new data with old parity

3 - write new data and new parity simultaneously.

Raid1 will only let you wait until data is written to both disks 'simultaneously'.

As for throughput for writing: 4 iops needed on R5, and 2 on R0+1. 4 disks R5
have the same throughput as a 2 disk mirror.

Latency of the R5 will be double that of the mirror.

But R5 will have more capacity...

Thomas

 
 
 

Faster? Raid 1+0 or Raid 5

Post by xx » Fri, 20 Jun 2003 23:43:07




>> Is the RAID system software based or hardware based? i.e. do you have
>> a dedicated RAID controller or is it done using system software drivers?

> Both have good and bad implementations...

>> 1+0 RAID is pretty slow in that it requires double the amount of data
>> to be written to the disks, however, this can be done in parallel, so
>> its not so bad.

> There is absolutely no need for mirroring to be slower than writing to a
> single disk. For reading it is definitely faster: you get 2 disks to
> read from.

This is simply not true. In the case of writing, unless the disks are
syncronized using a PLL signal, you can be assured of an average of 1/2
the seek time delay between mirrors when writing to two disks at the
same time.

Second is the drivers, if you are using a software raid system.
Depending on how the OS decides to deal with the page-locked write
buffers, it may need to copy the data into two separate chunks of
memory, one for each drive/controller.

Quote:

>> RAID 5 performs better than RAID 3 as the parity is distributed across
>> multiple disks, but is usually slower than stripe/mirror because of
>> parity calculation.

> Not so much from the parity calculation itself, but because to write 1
> block one needs to read that block, then write it, calculate parity on
> the difference, then read the parity block, xor with parity, and write
> back. In the meantime that block on the other disks in the stripe must
> be locked...

Not so, the blocks that go with parity are almost always in cache at the
same time. It is unlikely that a writer will need to reread A or B to
recalculate C. Chances are it A is being written, B is in cache.

Quote:

> The alternative is to aggressively cache written data and hope you can
> assemble a full stripe width of data, on which you can calculate parity
> without reading anything back from disk, and writing everything in one go.

That is very likely.

Quote:

>> Also, one last thing, depending on your application, the RAID
>> technology comes in to play. A software RAID system using multiple
>> disks, each on their own SCSI controller, may have a better I/O
>> performance than a dedicated hardware RAID, as each disk can send data
>> to the controller simultaneously.

> I've seen a lot of seriously slow RAIDs. Both software and hardware
> (lots of internal controller cards are slow). Linux software raid is
> extremely fast, but does full resyncs after unclean shutdown and can't
> continue an interrupted rebuild, but will start over.

OK, that is an implementation issue. I typically do not like to use
Software RAID. I like good, fast, hardware RAIDs. Check out
www.infortrend.com, pretty slick controllers.

Quote:

>> I could go on, but suffice to say, it isn't a question of "which is
>> faster," it is a question of "which is faster in my application?"
>> Which is a different and much more involved question.

> True. First check whether write performance is an issue at all, given
> the number of disks and so on.

Absolutely.

- Show quoted text -

Quote:

> Thomas

 
 
 

Faster? Raid 1+0 or Raid 5

Post by Maxim S. Shatski » Sun, 22 Jun 2003 02:21:12


Quote:> Second is the drivers, if you are using a software raid system.
> Depending on how the OS decides to deal with the page-locked write
> buffers, it may need to copy the data into two separate chunks of
> memory, one for each drive/controller.

Is there any OSes which cannot build a second buffer descriptor as a
clone of the first, not requiring the memcpy()?

    Max

 
 
 

1. Advantages of RAID 7 over RAID 4 and 5

Regarding that discussion about the architecture and advantages of
the new RAID 7 versus the earlier RAID 4 and 5, I printed out a copy
of the discussion on the news groups and took it to the Storage
Computer booth at the Banyan International Users Group show and
conference this week, hoping to discuss it with Storage
Computer Director Technical Director John O'Brien (the author of
the various RAID 7 technical articles).  He was not at the show the
day I was there, so I left a copy of the news group questions with
one of the Storage Computer executives there.  I guess he was back
at Storage Computer headquarters in Nashua, New Hampshire, developing
RAID 8! :-)   The Storage Computer executives at the show read the
news group comments about RAID 7 and said they wanted to provide more
information shortly to the relevant newsgroups on their RAID 7
architecture.  They indicated that their RAID 7 disk array platforms
are primarily for Novell, Banyan, IBM RS/6000 & midrange, Wang, HP,
Sun, MIPS, Silicon Graphics, Stratus (SCSI only), DG, and VAX systems,
at least for right now.  They said that people who would like an
explanation of this right now could call them at Storage Computer
headquarters (603) 880-3005 "for the rest of the story."


2. Quality of software with HP 4100C

3. RAID 7 Is An Extension Of The 5 Berkeley RAID Levels

4. URGENT REQUIREMENT FOR SAP FICO TECHNO FUNCTIONAL CONSULTANT

5. Library of Berkeley RAID papers (was RAID info wanted)

6. Info Please on CPU's

7. Raid 7 Versus Earlier Raid 4

8. Duality

9. RAID 7 disk array platforms versus earlier RAID 4 & 5

10. RAID 7 systems in Japan -- Upcoming Tokyo RAID 7 Seminars

11. Raid 7 versus earlier Raid 4

12. RAID Advisory Board (RAID Host Interface Meeting - 19-April-93)

13. Raid 7 Versus Earlier Raid 4