On Thursday May 16, malkin@reldata.com wrote: > Hi, > > I have a basic question about Linux RAID implementation: how to recover or > restart a RAID set when the individual disks are moved to a different SCSI > ID, i.e. when their minor (or major or both) number(s) change? > > I've experimented with a RAID-1 configuration and found that whenever I move > one of the disks to a different SCSI ID, the set must be recovered manually > (i.e. raidhotadd) and the kernel initiates a full copy, even if raidtab is > manually updated (I guess the system simply looks at the superblocks as the > first choice). Is it possible to restart the set automatically or at least > avoid the full copy? > > Another question: is there a utility that could identify RAID sets before > they are started, such as display the superblock contents and verify whether > any devices are missing or have been moved? There seems to be a considerable > amount of code, both in kernel and in raidtools, that prints out the content > of the superblocks, but only if there is a problem or debug mode is > on. Get mdadm. http://www.cse.unsw.edu.au/~neilb/source/mdadm/ (1.0.0 is recommended, 1.0.1 is experimental). It should answer all your questions. NeilBrown > > The main reason behind these questions is the emergence of iSCSI devices > that could be connected in a random order thus breaking RAID functionality. > It would be nice to identify such devices up-front, make necessary > configuration changes and restart complete RAID sets without the full copy, > even if the disks come up as different major/minor numbers. Please let me > know if there's been any thinking in this direction. > > Thank you in advance, > Kirill > > > - > To unsubscribe from this list: send the line "unsubscribe linux-raid" in > the body of a message to majordomo@vger.kernel.org > More majordomo info at http://vger.kernel.org/majordomo-info.html - To unsubscribe from this list: send the line "unsubscribe linux-raid" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html