Cydrome Leader wrote:
Dan Rumney wrote:
There's nothing inherent in RAID-5 that makes it susceptible to
corruption due to continuous rebooting of the controller. Equally,

there's more disk writes per write from the host. If it's a controller
with volatile cache memory, and you're always losing power this could be a
problem.

If you are using a raid controller or array with no safe memory, that is
the first mistake. Presuming you care enough about the data to spend
for the 1/n overhead and write cycle overhead of raid.

If you write/change 1 bit on a RAID5 volume, the controller has to read in
64kB (just a typical value), recalculate parity across the drives, then
write it all back.

64k for a modestly low end raid controller.

Plain mirroring might still be 64kB stripes, but only across two disks,
not 3 or more.

Mirror used to be the norm in the midlevel unix boxen. Saw way more
propagations of error data than recovery from error unless there was
some additional software/hardware in between that could reasonably
unambiguously spot the good copy in reasonable scenarios. More often it
was used as a quick way to take a snapshot or clone a file system by
making and breaking mirrors.

there's nothing inherent in RAID-1 that makes it more robust in these
scenarios.

There's also less drives to possible have lost writes to with a mirror
than with RAID5. A crappy RAID1 controller may not even notice that the
data across both disks doesn't match though.

Yup.

If the corruption is being caused by the controller it doesn't matter if
you have mirrored copies of your data; the controller will just write
the corruption to one or both copies.

Also, if the corruption is truly at the NTFS level, then you should be
looking at your filesystem and not the storage controller.

True, but if a controller is writing garbage to disk, NTFS will notice.

Not until it reads it. :-)