Re: transferring RAID-1 drives via sneakernet
I just finished the transfer and it went great. Thanks for all the advice. I went with the assemble-by-uuid approach in /etc/mdadm.conf which did very well. Especially since drive letters danced around quite a bit between reboots. One of the disks died during transit, and the redundancy part of RAID earned its keep. The only thing I didn't figure out was SATA hotplug. The SATA controller (an Areca 1230 in JBOD mode) happily noticed when a drive was hotplugged into a port. But Linux didn't seem to notice. I was using cfdisk to probe. Is there a particular command needed to convince Linux to look around and see if there are any new SATA devices? Jeff - To unsubscribe from this list: send the line unsubscribe linux-raid in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: transferring RAID-1 drives via sneakernet
Jeff Breidenbach wrote: It's not a RAID issue, but make sure you don't have any duplicate volume names. According to Murphy's Law, if there are two / volumes, the wrong one will be chosen upon your next reboot. Thanks for the tip. Since I'm not using volumes or LVM at all, I should be safe from this particular problem. If you don't use names, you use numbers - like md0, md10 etc. The numbers, as they now ARE names, should be different too. There's more to this topic, much more. There are different ways to start (assemble) the arrays. I know at least 4 - kernel autodetection, mdadm with mdadm.conf listed some devices, mdadm with empty mdadm.conf and with using of 'homehost' parameter (assemble all our arrays), and mdrun utility. Also, some arrays may be assembled during initrd/initramfs stage, and some after... The best is either mdadm with something in mdadm.conf, or mdadm with homehost. Note that neither of these ways, your foreign array(s) will be assembled, and you will have to do it manually - wich is much better than to screw things up trying to mix-n-match pieces of the two systems. You'll just have to figure the device numbers of your foreign disks and issue an appropriate command, like this: mdadm --assemble /dev/md10 /dev/sdc1 /dev/sdd1 ... using not yet taken mdN number and the right device nodes for your disks/partitions. If you want to keep the disks here, you can add the array info into mdadm.conf or refresh superblock to have new homehost. But if you're using kernel autodetection or mdrun... well, I for one can't help here, -- your arrays will be numbered/renumbered by a chance... /mjt - To unsubscribe from this list: send the line unsubscribe linux-raid in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: transferring RAID-1 drives via sneakernet
Jeff Breidenbach wrote: It's not a RAID issue, but make sure you don't have any duplicate volume names. According to Murphy's Law, if there are two / volumes, the wrong one will be chosen upon your next reboot. Thanks for the tip. Since I'm not using volumes or LVM at all, I should be safe from this particular problem. Volumes is being used as a generic term here. You would be safest if, for the disks/partitions you are transferring, you made the partition type 0x83 (linux) instead of 0xfd to prevent the kernel autodetecting. Otherwise there is a risk that /dev/md0 and /dev/md1 will be transposed. Having done that you can manually assemble the array and then configure mdadm.conf to associate the UUID with the correct md device. David - To unsubscribe from this list: send the line unsubscribe linux-raid in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: transferring RAID-1 drives via sneakernet
Jeff Breidenbach wrote: I'm planning to take some RAID-1 drives out of an old machine and plop them into a new machine. Hoping that mdadm assemble will magically work. There's no reason it shouldn't work. Right? old [ mdadm v1.9.0 / kernel 2.6.17 / Debian Etch / x86-64 ] new [ mdad v2.6.2 / kernel 2.6.22 / Ubuntu 7.10 server ] I've done it several times. Does the new machine have a RAID array already? David - To unsubscribe from this list: send the line unsubscribe linux-raid in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: transferring RAID-1 drives via sneakernet
It's not a RAID issue, but make sure you don't have any duplicate volume names. According to Murphy's Law, if there are two / volumes, the wrong one will be chosen upon your next reboot. Thanks for the tip. Since I'm not using volumes or LVM at all, I should be safe from this particular problem. - To unsubscribe from this list: send the line unsubscribe linux-raid in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: transferring RAID-1 drives via sneakernet
Jeff Breidenbach wrote: Does the new machine have a RAID array already? Yes.. the new machine already has on RAID array. After sneakernet it should have two RAID arrays. Is there a gotcha? It's not a RAID issue, but make sure you don't have any duplicate volume names. According to Murphy's Law, if there are two / volumes, the wrong one will be chosen upon your next reboot. -- Brendan Conoboy / Red Hat, Inc. / [EMAIL PROTECTED] - To unsubscribe from this list: send the line unsubscribe linux-raid in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: transferring RAID-1 drives via sneakernet
Does the new machine have a RAID array already? Yes.. the new machine already has on RAID array. After sneakernet it should have two RAID arrays. Is there a gotcha? - To unsubscribe from this list: send the line unsubscribe linux-raid in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
