Gregory Leblanc writes:
...
 > > I know that the Linux kernel auto-detects the SCSI devices on boots
 > > and assigns them
 > > 
 > > /dev/sda to the first one
 > > /dev/sdb to the second one ...
 > > 
 > > and so on.
 > 
 > Yep.  Lots of planning done there.  :-)
 > 
 > > Doesn't this put a kink in your plans if you remove a disk physically
 > > and then restart the system?  I mean, what if the failiure on the disk
 > > is something like smoke coming out of the drive bay and the next time
 > > you reboot the kernel doesn't even see the device?
 > 
 > If you're using just the SCSI drives, yes, it screws everything up.  
 > 
 > > Is there a way to hard code /dev/sda to Target ID N and /dev/sdb to
 > > Target ID M so that in case N fails, your old /dev/sdb doesn't show up
 > > as /dev/sda when you reboot?
 > 
 > Sort of.  There are some "devfs" patches that make the /dev filesystem MUCH
 > cleaner, and they keep disk at the same location, even when other disks are
 > removed.  It does break a few things though.  I don't think it currently
 > works with RAID, at least not on 2.2.x
 > 
 > > The setup I'm envisioning is a 2.2.16 kernel with the latest patches,
 > > a single SCSI bus with 2 hard drives in a RAID 1 configuration.  If it
 > > makes a difference, the system will NOT boot from these disks.
 > 
 > Well, with persistent superblocks, you don't have anything to worry about.
 > The kernel will just detect your RAID sets, and configure them.  Then, since
 > /etc/fstab is pointed at /dev/mdX rather than /dev/sdX, you don't have to
 > worry about SCSI drives changing.  HTH,


Thanks for the response.  Unfortunately, I don't think this setup
would help my situation very much, because this is on a shared SCSI
bus configuration.  Autodetection screws everything up, because when the
second machine is booted, it shouldn't have "permission" to access the
disks.

Is there a way for me to take advantage of the persistent superblock
without kernel auto detection?  Basically, I don't want to start the
RAID device until I say, "GO" (after we are sure the peer system is no
longer accessing the devices.)

-Eric.

Reply via email to