RE: iSCSI: login issue - partial consensus call

["Jim Hafner" <hafner@almaden.ibm.com>]

Eddy,

I think the scenario you're talking about isn't really that big a deal;
I've argued this sort of thing before.

First, it's really the target that has to remember (for reservations) the
ISID that was used for a given initiator *through the target's reset*, not
through the initiator reset.

Consider: the target cannot tell the difference between a crash of the
session (network failures) and a crash of the initiator.  Similarly, the
initiator cannot tell the difference between a crash of the session
(network failures) or a crash of the target.  The guarantee here is that
*from a LIVE initiator's point of view*, a change in the target shouldn't
affect it's world.  So, while the initiator is LIVE, it should be able to
recover the world it had once it can recommuniciate with the target.
There is no obligation on the part of the target to recover the initiator's
view of the world through initiator failures unless the initiator
re-identifies himself as the same old guy.

Now, for the initiator that detects the failure (network or target, it
can't tell) and is still live, it already has everything it needs to
re-identity itself.  For the initiator that failed, there's no real point
it re-identifying itself even if it had a reservation (if it didn't, the
point is moot).  There's only two cases to care about here. Either no one
else in the cluster has pre-empted the reservation OR someone else in the
cluster has done that.  In the first case, if it knows it wants the
reservation back, it can pre-empt it's own reservation.  In the second
case, there's nothing to worry about cause the reservation it had is gone
and the target has no necessary state for it.

In short, I think we're overworking this problem of the initiator
rebuilding its old word after it's own failure.  That's a recovery case
that must be handled for lots of reasons, not just getting back the ISID.
The key is really what the target has to remember AND what the unfailed
initiator has to do for recovery thru network or target failures.

Jim Hafner


"Eddy Quicksall" <eddy_quicksall@ivivity.com>@ece.cmu.edu on 09/12/2001
11:38:29 am

Please respond to <eddy_quicksall@ivivity.com>

Sent by:  owner-ips@ece.cmu.edu


To:   "'David Dillard'" <david.dillard@veritas.com>, "'Martin, Nick'"
      <Nick.Martin@compaq.com>
cc:   <ips@ece.cmu.edu>
Subject:  RE: iSCSI: login issue - partial consensus call



One thing to keep in mind when assigning the ISID's via the registry is
that
the drivers will have to get the same set of ISID's when they re-boot after
a failure.

Considering the following, is that possible?

- the client crashes
- maintenance notices that the reason for the crash was due to a short in
one of the iSCSI HBA's
- so, maintenance pulls out that HBA
- he re-boots
- during the re-boot, the drivers come up in a different order because one
is missing

Eddy

-----Original Message-----
From: David Dillard [mailto:david.dillard@veritas.com]
Sent: Tuesday, September 11, 2001 9:28 AM
To: 'Martin, Nick'
Cc: 'ips@ece.cmu.edu'
Subject: RE: iSCSI: login issue - partial consensus call


Not to turn this into a Microsoft Windows driver reflector but...


> There are a number of conditions which can cause this information
> to be incorrect. (As an example two different controller models
> supported by the same driver will each be treated as instance 0
> and get the same command line.)

There is a documented way of handling this issue.  See KB article Q133706.

I believe there is a much larger issue, that you brought up in a later
posting: that miniports cannot legally, and perhaps illegally, use the
registry access routines.


David