I understand what you are saying about this not being an OpenBSD or a
raidframe problem. I will try that tool you pointed me to and see what it
says. Will it permanently mark the blocks as bad? If the worst happens I'm
going to have to rebuild the system, but I don't want it to use those
I've tried, again, to fix my raid array with raidctl -R. I did it on the
console port this time so I could capture the output from ddb
Here is some output:
# raidctl -s raid0
raid0 Components:
/dev/wd0d: failed
/dev/wd1d: optimal
No spares.
Parity status: DIRTY
On 7/17/06, Jason Murray [EMAIL PROTECTED] wrote:
I've tried, again, to fix my raid array with raidctl -R. I did it on the
console port this time so I could capture the output from ddb
Here is some output:
yay!
I then use raidctl -S to monitor the reconstruction. Things go well
until the
Jason Murray writes:
I've tried, again, to fix my raid array with raidctl -R. I did it on the
console port this time so I could capture the output from ddb
Here is some output:
# raidctl -s raid0
raid0 Components:
/dev/wd0d: failed
/dev/wd1d: optimal
No spares.
Jeff Quast writes:
My first few months with raidframe caused many kernel panics. With 30
minutes of parity checking, this was a difficult learning experience.
I was initialy led to beleive that raidframe was hardly stable (and
therfor disabled in GENERIC).
However, as I gained experience
Is it standard practice to use raidctl on a raid set while your system is
running from that raid set?
I'm just curious as to what best practice might be?
Last night I booted to a different disk so I could run raidctl -R against the
array while it was not being used. That caused a kernel panic
On 7/11/06, Jason Murray [EMAIL PROTECTED] wrote:
Is it standard practice to use raidctl on a raid set while your system is
running from that raid set?
I'm just curious as to what best practice might be?
Last night I booted to a different disk so I could run raidctl -R against the
array while
7 matches
Mail list logo
