Scott Silva wrote on Thu, 08 Jun 2006 09:29:12 -0700:
Pardon my chiming in,
why should I take offense? Thanks!
but this is an adequate way to copy the partition data,
and that is what I used on my software raid systems. Don't forget that the first part is sfdisk -d, not just sfdisk -.
Yeah, my typing! Thanks for the confirmation, I'll put it in my basket of valuable snippets.
the pulled out one. I didn't test dropping one of the disks in the middle of operation yet.
Don't do that! Don't test by pulling a running disk unless it is in hotplug capable hardware. Test by using mdadm to remove that drive.
That's not a real test ;-) I can test out and learn quite a few things by less harmful ways but I don't know what happens if I rip it out in the middle of operation. After all, that's what's going to happen when it really fails. I did it already once and the drive survived, I'll do it again. I use two old 10 GB drives for testing. I'd regret if I lost one of them since after that I have only *very* old drives for further testing, but it's not a real problem.
There are two things I realized:
- disks need to run on different IDE controllers it seems.
That info is in the software raid howto. Some systems are more tolerant than others, but usually a failed drive will lock the entire channel, so the primary and the slave would go down.
Yeah, I didn't read that part of the how-to I guess. On a non-testing machine I wouldn't have put the drives on one channel, anyway, but in this case it was the easiest and fastest option. And I learned something from that :-) Actually, they didn't go down both, but the bootup failed. There was a whole lot of IDE errors on the console, though, after I pulled the cable.
Kai