On Mon, 1 Jul 2013, Henri Kemppainen wrote:
> > From owner-source-changes+M72344=duclare=guu...@openbsd.org Mon Jul 1
> > 14:33:54 2013 Delivered-To: ducl...@guu.fi
> > From: Joel Sing <js...@cvs.openbsd.org>
> > To: source-chan...@cvs.openbsd.org
> > Subject: CVS: cvs.openbsd.org: src
> > Sender: owner-source-chan...@openbsd.org
> >
> > CVSROOT: /cvs
> > Module name: src
> > Changes by: js...@cvs.openbsd.org 2013/07/01 05:33:21
> >
> > Modified files:
> > sys/dev : softraid.c
> >
> > Log message:
> > When an I/O error occurs on a softraid chunk, only take it offline if the
> > discipline supports redundancy. In the non-redundant case, there is
> > little to gain my failing the chunk, in fact it just makes any form of
> > data recovery significantly harder.
> >
> > ok krw@ todd@
>
> Would it make sense to behave like this when the discipline supports
> redundancy, but redundancy isn't actually available? I had this happen to
> me when one mirrored drive went offline, and during rebuild the remaining
> "good" drive had a transient hiccup, taking the whole thing down.
The short answer is "yes". The longer answer is that this is a more indepth
change, since it becomes discipline specific. If I had a three chunk RAID 1
volume it would not reach the non-redundant point until I lost two of the
three chunks, whereas for a RAID 5 volume this happens after a single chunk
is lost. It is, however, on my TODO list.
--
"Action without study is fatal. Study without action is futile."
-- Mary Ritter Beard
