Kurt Garloff wrote:
>
> On Fri, Aug 11, 2000 at 11:16:04AM -0500, David Teigland wrote:
> > On Fri, Aug 11, 2000 at 09:35:19AM -0500, Mark Veteikis wrote:
> > - Hot-swapping SCA disks on the bus should be relatively reliable if it's done
> > with care. It sounds like if any transfer is happening during a swap you're
> > in serious danger of crashing everthing. The scsi drivers can be prompted to
> > add or remove devices. I wonder if multiple hosts put a wrench in things
> > here.
>
> If the electrical problems are solved by using SCA, it should not be
> dangerous to have a tranfer going on on the bus to another device at the
> same time. I have no experience with SCA myself.
>
There is electrical and then there is electrical. In theory, it is a
bad idea to remove or add a SCSI device while a transfer is taking
place. Why? Basically, the capacitive load on the SCSI bus changes
when drive contacts are made or broken i.e. the transmission line
characteristics of the bus change and that affects the signal in
flight. Since transfers during the data phase are only protected by
parity, undetectable errors might occur.
Having said that, empirical evidence points to this type of failure
being exceedingly rare for older versions of SCSI with restricted
configurations and qualified components. Personally, I take
the approach that something I can't prove won't happen...can happen
and most likely will.
Some people take the opposite view and they are mostly happy most of
the time. :)
> > - The other important issue is hosts which crash at any time, including during
> > a transfer. It sounds like the drivers on other machines will currently
> > start a reset-war, but the drivers could be improved to avoid this and
> > hopefully keep using the devices as they were.
>
> I can only comment on the Linux SCSI drivers that I have hacked on. They all
> are old EH. As faar as I can see, they are not proe to reset wars. When they
> see a bus reset (they monitor for this), they reset all their negotiated
> settings (Sync, Wide, ...) and return all SCSI commands back to the
> mid-layer wit DID_RESET. The mid-layer will just requeue them (in the order
> it got it, so the low-level authors need to make sure to pass them back in
> the right order).
> As I have multiple host adapters on the same bus (in one machine though), I
> have this situation and never got reset wars.
>
> A crash during a sync transfer is indeed bad, as the bus will be kept busy
> and you will need at least one reset to clear it. If the host adapter on a
> crashed machine keeps the bus locked and does ignore the SCSI bus reset,
> you're lost of course, but I don't think that it's that likely.
>
> > - A similar problem for devices which crash abruptly.
> >
> > - How about adding machines to the bus and then booting them up?
>
> If the SCSI adapter in the new machine does strange things to the bus on
> power up, you may have problems; but apart from that, there should not be
> any problems.
>
> That's theory. Some buggy firmwares out there may not handle many initiators
> correctly. THe hard disks that I tested so far, all behaved correctly, though.
>
> > By the look of things here, it is not reasonable to use GFS with multiple hosts
> > on a shared SCSI bus if you're interested in HA. If any machine or disk
> > crashes, all your devices are probably in trouble. Stopping all machines' I/O
> > (and maybe unmounting everyone) to add or remove storage would also be
> > prohibitive.
>
> I would not be so negative.
>
> Regards,
> --
> Kurt Garloff <[EMAIL PROTECTED]> Eindhoven, NL
> GPG key: See mail header, key servers Linux kernel development
> SuSE GmbH, Nuernberg, FRG SCSI, Security
>
> ----------------------------------------------------------------------------
> Part 1.2Type: application/pgp-signature
--
Dan Jones, Manager, Storage Products VA Linux Systems
V:(408)542-5737 F:(408)745-9911 1382 Bordeaux Drive
[EMAIL PROTECTED] Sunnyvale, CA 94089
-
To unsubscribe from this list: send the line "unsubscribe linux-scsi" in
the body of a message to [EMAIL PROTECTED]
