Re: SCSI device hung: What happens if I turn it off ?

From: Logan Shaw (lshaw-usenet_at_austin.rr.com)
Date: 11/11/03 

Date: Tue, 11 Nov 2003 19:43:18 GMT

Guy Dallaire wrote:

> I've got a tape drive + loader (Quantum DLT4500) connected to the external
> SCSI port of a fully loaded UE450, solaris 2.6. If I remember well, that
> SCSI port is on the same channel as the CD-ROM and some internal disks (But
> I'm not sure, how can I check this)

Do "ls -l /dev/dsk" and "ls -l /dev/rmt". Note where the symbolic links
point to. That should tell you if they're on the same controller.

Alternatively, you can do "prtconf | grep -v 'driver not attached'"
and look at that output. It's less verbose but in my opinion more
confusing.

> What happens when you turn off a device on a SCSI chain ? Will I lose data
> on other devices ? Will the system panic ? When you turn it back on, will
> the system "see" it ?

I'm not sure whether it's officially supported. It could be officially
OK to do that and I don't know it, but actually I doubt that turning
off power to a SCSI device is a supported thing to do. It may even
depend on the device.

However, having said that, I do it often enough on my home Solaris
system with an Exabyte 8200 tape drive, and I've never experienced
a problem. And that drive shares the SCSI bus with a hard drive that
is my main drive. So, practically, it may be OK.

If you do turn off the device while the bus is in operation and
if this causes a problem, I believe SCSI has parity and other
safety mechanisms. You probably will not experience corruption of
your data.

I suppose there is a chance you could cause a problem for one of the
device drivers. Disturbing the bus might cause a request to fail and
put the system in a state that the driver didn't expect. However,
most drivers should be robust enough to handle this. Most systems
(including Solaris systems) should fall back to resetting the entire
SCSI bus if they have problems. You see this on systems with bad
SCSI cabling or termination, and most of the time the system keeps
on trucking after the initial hiccup of the bus being reset.

Another important question to consider (besides safety) is whether
this will actually do you any good. Power cycling the drive will
surely reset the drive, but will the st (scsi tape) device driver
understand what has happened and be able to use the drive? This I'm
not sure about.

If you should decide to go ahead with the power cycling, there are
a couple of things you could do to make it a little safer.
Basically, the goal is to try to be sure that no activity is happening
on the bus while you do it. Here are a couple of ways to do that:

(1) If you have swap space on a disk on that SCSI bus, and if you
      have enough memory or swap in other places, use "swap -d" to
      delete the swap space. Then later add it again with "swap -a".
      Be sure to use the same device with "swap -a" that you used
      with "swap -d"; if you have a typo and add the wrong device,
      you may cause yourself problems!

(2) If you have a filesystem on a disk on that SCSI bus, and IF THE
      FILESYSTEM IS NOT A SYSTEM FILESYSTEM like /usr, /, /var, and
      so on, you could use "lockfs -w /mount/point" to prevent writes
      to the filesystem beforehand and "lockfs -u /mount/point" to
      unlock it afterwards. (You can use "lockfs -a" to see the
      current lock status of all filesystems.) This will cause any
      program that tries to write to the filesystem to block until
      you unlock the filesystem. So, many processes will seem to
      hang, but they will un-hang when you do lockfs. The reason
      I say to avoid system filesystems is that you might cause an
      important command to hang and you could end up not being able
      to ever type "lockfs -u" to unlock it. Needless to say, you
      might as well just reboot at that point (something you're
      trying to avoid).

(3) Whatever you do, you want to type "sync" and then wait a few
      seconds right before you do the power cycle. This can be
      combined with the above, or it could be done by itself.

Personally, I'd do all three of these, but you probably want to
think carefully before doing #2, and anyway if you have a system
disk on that SCSI bus it's not going to be applicable anyway.

A wholly different way of approaching this is that you might be
able to reset the device from software. I'm not SCSI guru, but
I believe the controller can send a command to a device telling
that device to reset itself. There are some utilities out there
that let you manually send raw SCSI commands to devices. You
could probably use one of those to send a reset command to the
device and see what happens. It might have the same effect as
power cycling, or maybe not.

   - Logan

Relevant Pages

  • Re: HDD upgrade 9000 E35
    ... > Hook it to the scsi bus and use it as additional space. ... > the disk a free address, not the ones used by the build-in disk or ...
    (comp.sys.hp.hpux)
  • SYM53C8XX help
    ... SCSI related. ... sym0: SCSI BUS reset detected. ... md: Autodetecting RAID arrays. ...
    (Linux-Kernel)
  • Re: Two computers sharing a external hard drive at the same time
    ... > A long time ago with SCSI devices I discovered that it is technically ... > virtual SCSI bus as a host adapter, and if so, can you set the SCSI ID ... both computers b8uffer the disk sectors independently, ... Tauno Voipio ...
    (comp.os.linux.networking)
  • Re: Q about Adaptec 29160
    ... The SCSI bus itself can do 160MB/sec, sure, but not the disk. ... read speeds are always lower. ...
    (comp.os.linux.hardware)
  • Re: BIOS not seeing bootloader
    ... What I see is the same on my third disk was it is the ... > the second disk must be different at the drive selector byte. ... But it wouldn't be hard to toy with the SCSI IDs for the ... and disk 2 on the SCSI bus. ...
    (comp.os.linux.hardware)