> After the reconstruction succeeded, RAIDframe seems to be confused > about the state of sd3a:
> Components: > /dev/sd2a: optimal > /dev/sd3a: spared > /dev/sd4a: optimal > /dev/sd5a: optimal > /dev/sd6a: optimal > /dev/sd7a: optimal > /dev/sd8a: optimal > /dev/sd9a: optimal > Spares: > /dev/sd3a: used_spare I don't think that's really an accurate way of saying it. Rather, I'd say that you have told it to use sd3a twice, in two different roles, and the result is confusing you because your mental model doesn't match what's actually going on. I feel reasonably sure that raidframe does not realize the two "/dev/sd3a"s refer to the same thing, so there is no single thing it's confused about. > How do I get out of this? In my experience, the only way to get out of a "used hot spare" state is to unconfigure and reconfigure. Last time I looked (which was the 4.x code), the code included an interface for dealing with such situations, but nothing was implemented for it. > Or how can I make sure what has really been written to the component > label of sd3a? Look at it? That sounds flippant, but it's not. One of my beefs with raidframe is that it doesn't include tools for that sort of thing. I wrote my own as a result, which anyone interested is welcome to a copy of. It might even compile and run! :) git://git.rodents-montreal.org/Mouse/rfprobe for them as have git set up; ftp.rodents-montreal.org:/mouse/hacks/rfprobe.src/ for those who would rather FTP it. /~\ The ASCII Mouse \ / Ribbon Campaign X Against HTML [email protected] / \ Email! 7D C8 61 52 5D E7 2D 39 4E F1 31 3E E8 B3 27 4B
