Re: Four Drive RAID-5 on RAIDFrame Considered Harmful...

Greg Troxel writes:
>   Setting it up initially, I raided the 4 drives
together with two
>   partitions on each of the components: a small one for
RAID-1 to load
>   the kernel, and a large one for RAID-5. 
Unfortunately, the RAID-5 had
>   horrible performance: 2-3MB/sec sometimes and never
higher than about
>   12MB/sec.
> 
> I am not 100% clear on this, but I have the impression
that RAID-5
> requires read-modify-write 

There is no 'requirement' for that.  You might end up having
to do 
that, depending on configuration settings, but the reality
is that 
you want to avoid r-m-w as much as possible.

> and that in the event of system crash or
> power loss you can get corruption, 

What sort of corruption would you like?   In
general, the filesystem
corruption that you'd see is about the same as what you'd
see with a 
single disk.  Where there is a chance for "more
corruption than with 
a single disk" is if a component fails before parity
has been 
completely verified.  In that case, if incorrect parity is
used to 
reconstruct lost data, that lost data might be gone for good
(and bad 
data returned).  Of course, you could get that same sort of
bad data 
on any filesystem that overwrites files in-place, and the
system 
happens to go down at an inopportune moment...

> and thus the good hardware
> controllers have a) battery backed RAM and b) code that
won't crash.  (I
> don't mean to malign the raidframe code - but because
it's in-kernel if
> the kernel crashes for any reason - not unheard of -
then pending raid
> writes may not happen.)

Right.  Just like any other pending writes to anything won't
happen.
 
> Because of this I've always just bought two big disks
and done RAID-1.

RAID 1 has the same issue -- Say the machine dies at the
point where
block n is written to component 0 but not to component 1. 
If 
component 0 dies before block n gets synced between the two,
then 
when you read block n from component 1, you're going to get
the old 
data.

> Perhaps Greg Oster will chime in, and it would be a
good addition to the
> Guide to discuss the wisdom of using RAID-5.
> http
://www.netbsd.org/docs/guide/en/chap-rf.html

The reality is that RAID (hardware or software) is not a
panacea, and 
you're just attempting to bump the odds in your favour.  And
just like 
there is a non-zero chance of corruption, there is also a
non-zero chance 
that all your disks won't die at once, or that a power surge
doesn't 
take out your hardware raid configuration.

Personally, I like the odds that I'll be able to get a
parity rewrite 
done in time, vs. the odds of having my only disk die. 

Later...

Greg Oster

On Wed, Oct 10, 2007 at 02:59:37PM -0600, Greg Oster wrote:
> Greg Troxel writes:
> > Because of this I've always just bought two big
disks and done RAID-1.
> 
> RAID 1 has the same issue -- Say the machine dies at
the point where
> block n is written to component 0 but not to component
1.  If 
> component 0 dies before block n gets synced between the
two, then 
> when you read block n from component 1, you're going to
get the old 
> data.

It's not exactly the same. IMHO old (in RAID1 case) is
better than
random (in RAID5 case).

-- 
Pawel Jakub Dawidek                       http://www.wheel.pl
pjdFreeBSD.org                           http://www.FreeBSD.org
FreeBSD committer                         Am I Evil? Yes, I
Am!

On Wed, Oct 10, 2007 at 02:59:37PM -0600, Greg Oster wrote:
> Greg Troxel writes:
> > Because of this I've always just bought two big
disks and done RAID-1.
> 
> RAID 1 has the same issue -- Say the machine dies at
the point where
> block n is written to component 0 but not to component
1.  If 
> component 0 dies before block n gets synced between the
two, then 
> when you read block n from component 1, you're going to
get the old 
> data.

I am curious - what do the BIOS-based software RAID
controllers (as
offered by e.g. Promise and supported by ataraid(4)) do to
correct the
situation when block n is written to component 0 but not 1?
AIUI, you have
to do a re-sync after such unclean shutdown (hoping that the
component
won't die before the data are synced) or have a battery
backed cache.
So, do those "RAID controllers" re-sync parity
after unclean shutdown?

Pavel