"Brian A. Seklecki" writes:
> raid(4) hasn't been touched in a while (years), so short answer: No.
>
> NetBSD is still actively committing to it, though, and has functional
> background parity recalculation.
Just to be clear here: the background parity checking in NetBSD as of
today is functionally the same as what OpenBSD has right now.
The implications here are as follows: if the parity is checked in the
background, and a non-parity component should fail, there is a very
low, but non-zero probability of data loss. The longer it takes to
check (and correct, if necessary) the parity, the greater the chance
of loss. The value of your data should dictate whether you can live
with that increase in risk.
For the record, I do the parity checking in the background on all the
machines I look after. Since most of them can complete the check in
under an hour, there is that one hour window where some fragments of
corruption *may* have occurred (and that didn't get caught with a
filesystem check).
> I understand there is interest in replacing RAIDFrame instead of
> resynchronizing the subtree.
>
> In the mean time, find a hardware RAID Controller that can be managed by
> OpenBSD via bio(4) and grab a UPS that works with upsd(8).
I worry more about a hardware RAID card forgetting its configuration
after a power outage than I do about parity checking in the
background :) ("What do you mean these 14 disks in this 2TB hardware
RAID array are now all 'unassigned'!?!?!?!". That wasn't a fun day.)
Later...
Greg Oster
> On Thu, 27 Sep 2007, Rob wrote:
>
> > On 9/25/07, Matt <[EMAIL PROTECTED]> wrote:
> >> I'm running a RAID1 mirror on OpenBSD 4.1 (webserver)
> >> On a power failure the parity becomes dirty and needs rewriting, which
> >> results in > 1.5 hours 'downtime'.
> >> Is it safe to background this in /etc/rc or is that a no-no?
> >>
> >> I found a reference this was possible/safe on-list but it was a) 2003
> >> and b) dealt with RAID5.
> >> I'd like to make sure I am not doing something dangerous.
> >
> > I frankly don't know enough to guarantee that this is safe, or not,
> > but I had a RAID1 with big disks on an ancient machine that took about
> > 26 hours to check parity (! -- this wasn't my idea), and I modified
> > its rc to boot up, and then begin performing the parity check in the
> > background.
> >
> > The only caveat I would give is that the operating system was
> > installed and running on a 3rd, separate disk, and that network access
> > to the mirrored drives was disabled until the parity rewrite was
> > complete.
> >
> > - R.
