On Thu, 2006-11-16 at 14:56, Martijn van Oosterhout wrote: > On Thu, Nov 16, 2006 at 12:40:41PM -0800, Glen Parker wrote: > > But now, pull the drive from port 2 and boot the system. You will now > > have SDA,SDB,SDC. The kernel will now fail BOTH of the last two drives > > from the RAID array. The one that was SDC is gone, and obviously fails. > > The one that was SDD is now SDC, so its ID doesn't match what the > > kernel thought it should be, so it fails it too. If you kill the FIRST > > drive in the array, I believe the entire array becomes inoperable > > because of the resulting shift and ID mismatch. > > Is that really so? AIUI the position of the disk in the array is stored > on the disk itself, so it should be able to handle disks moving around > no problem, have you tried it? Just FYI, I've tried this before. yes, linux software RAID, knowing that the linux scsi numbering system is non-deterministic, is designed to handle this. In fact, you can build a RAID5 or RAID0 array of as many disks as you like, shut down the machine, change every single drive ID, and the machine will still find the RAID arrays. Last I tested this was on something like RH 7.2 by the way. Times may have changed, but I can't imagine someone being stupid enough to break the RAID array handling that worked so well back then. > > > So the question is, is there some way to "pin" a drive to a device > > mapping? In other words, is there a way to force the drive on port 0 to > > always be SDA, and the drive on port 2 to always be SDC, even if the > > drive on port 1 fails or is pulled? > > I thought you could do this with options on the command-line, or using > udev. But I don't think it's actually necessary. You can, it's generally not.
