Pavel Cahyna <pavel@netbsd.org> writes:

> 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.

But that's ok - the property that if you crash near a write you get
either the old data or the new data means that the RAID set behaves like
a non-failing disk, and that's ok. 

My concern about RAID-5, which seems to be addressed by judicious stripe
size choices, is that I thought it was possible to have the system go
down, without any failures, and after reboot/reconstruction have bits
that were not either the old or the new.

It would be really nice to explain this and what stripe sizes to use in
the RAIDframe section of the guide.  I definitely don't understand this
well enough to give advice - just enough to be worried.

> 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?

That's a good question - I have assumed they do a parity rewrite much
like RAIDframe does.  I have the impression none of the included raid
features have battery backed caches (that's for expensive cards, which
may well be worth it), and I don't see how else they could work.  I have
avoided using BIOS raid because the feature of raidframe that I can
mount one of the disks in any machine and get at it is comforting for
recovery from problems.