I just want to affirm James' point. Any SCSI (i.e. bus-based)
multi-initator configuration will require intelligent handling
of reset. The best case would be where every initiator got a
chance to vote whether a reset should be issued. Since there
are good reasons why that won't happen, not the least of which
is that there would still have to be an override case, the next
best solution is not to break out a reset unless nothing else
is left to try. Hmmm, this may ultimately be a case for separate
SCSI buses for different classes of devices.
Anyway, based on my experience in the past, SCSI drivers tend
to believe that god intended only one host for each SCSI bus and,
when in multi-initiator configuration, a driver of that design
has a propensity to get into reset wars of the "oh yeah, take that!"
variety.
As long as I am writing on the topic, another problem for
multi-initiator is when each layer in the boot sequence decides
that the best way to proceed is to make no assumptions on the
current state of the SCSI interface and to issue a reset. This
problem is normally solved by hiring a gorilla to flip the power
switches of the enclosures with both initiators at the same time
when the systems are more than 6 feet apart.
James Bottomley wrote:
>
> [EMAIL PROTECTED] said:
> > I tried to add some logic to the mid level driver [core] so that the
> > upper level drivers (specifically sg under superuser's instruction)
> > could request a SCSI bus/device/host reset. Basically the patch was
> > rejected because it might interfere with the mid level's error
> > processing.
>
> We really need to modify the mid level's attitude to resets, otherwise we're
> going to get killed on fibre channel (which is basically a huge
> multi-initiator environment). Once you have more than one initiator on a bus
> (or SAN ring) a reset can come at any time or stage during command processing
> (Linux actually exacerbates the situation by sending a reset on boot).
> Probably the way to hande this is some type of reset notify callback from low
> to mid layers. Drivers can detect bus resets directly. Device or LUN resets
> can be detected by unexpected Unit Attention conditions. At the moment
> external reset handling is done at the low level. Nice drivers (like the
> aic7xxx, sym8xx and most fibre drivers) detect resets and UA's, abort
> outstanding commands and return them to the mid level. Cards which handle
> reset processing correctly also correctly handle reset injection without
> causing problems to the mid level.
>
> Given the above, I really think it makes sense to provide a reset injection
> ability through the sg driver on a "caveat emptor" basis. If you have a low
> level driver that doesn't do reset processing, the chances are that the mid
> level error handling will get very confused. However, for a (reasonably long)
> list of cards reset injection will work correctly. Since reset injection is
> an essential facility for handling reservations in a SAN environment, I don't
> think it's necessary to reject it just because of a few bad low level drivers,
> just take the standard UNIX philosophy of letting root decide if it's safe or
> not.
>
> > My feeling is that in some contexts [best known to a user application
> > or an upper level driver] turning off the mid level's error processing
> > might be advantageous. There is also no way for an application or an
> > upper level driver to abort a SCSI command in progress. This means
> > that an application can't set an extremely long timeout to the SCSI
> > subsystem, run its own timer, and if that timer expires, abort the
> > outstanding command.
>
> That would be truly great and useful functionality!
>
> James Bottomley
>
> -
> To unsubscribe from this list: send the line "unsubscribe linux-scsi" in
> the body of a message to [EMAIL PROTECTED]
--
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]
