Re: Hot-pluggable SCSI
On Sat, 15 Oct 2005, Daniel Bauer wrote:
> From: "John Miller" <email@example.com>
> >I decided to add the scsiadd package. However, running scsiadd -s to
> >scan for the new device hung the server to the point of needing a
> >reboot. Got it back up and running, but I'm going to wait for our
> >scheduled downtime period before trying any more SCSI tricks, and in
> >meantime, I'd better RTF--HOWTO. I appreciate being able to receive
> >such prompt suggestions, and hopefully I'll be able to help in the
> maybe it depends on your hardware, what do you use? Is it a normal SCSI
> device or maybe a raid system?
You don't need to go that far, the kernel support for hotplugging SCSI is
very unstable (at least with some drivers?). In *all* kernels I have tried
so far, including 184.108.40.206.
Remove a disk from a hotplug bay, and try to access it: the entire SCSI
channel is locked (why? the controller IS responding, the disk isn't).
After a lot of hassle, the kernel and controler agree to disconect the
device, and then the kernel promptly goes bananas, instead of just failing
all IO to the disconnected device. Very crappy.
Never mind doing too much of scsiadd -s 0 0 (or wherever your hotswap bay
is), it ends up confusing the kernel and it borks. I've got oopses, and
hard lockups. scsiadd -a and -d are the same, do one of them too much, and
your system needs a hard boot. Running plain scsiadd -s (without a bus id)
is tantamount to suicide in my experience.
These issues happened with an Adaptec 79xx on board, some 78xx on board, and
(not completely sure about this one) a lsi-logic U320 SCSI HBA. The hotswap
bays were from intel, one with a U160 backplane, the other with a U320 one.
"One disk to rule them all, One disk to find them. One disk to bring
them all and in the darkness grind them. In the Land of Redmond
where the shadows lie." -- The Silicon Valley Tarot