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: > > > > 1. 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 -- Kai Schätzl, Berlin, Germany Get your web at Conactive Internet Services: http://www.conactive.com