Re: iSCSI Autosense

[Ralph Weber <ralphoweber@compuserve.com>]

Julo,

I hope Somesh will forgive me for butting in on his
discussion topic.

} I have on objection on making Autosense mandatory and
} removing the bit from iSCSI.
}
} My issue (if it is an issue) is SCSI related.
}
} How are asynchronous events that are not error related
} handled without Contingent Allegiance - and what effect
} will it have on iSCSI.
}
} The case that was raised a while ago (by Costa I think)
} was that of a volume change - with the message reporting
} it "crossing" a write on the wire or in the OS.
}
} With CA the state synchronization can be easily enforced
} (command are rejected until a sense is received).

Please understand that this description is not how CA works.
With CA, commands are rejected only until another command is
received from the same initiator that got the CHECK CONDITION
status.  That command, whatever it is, gets processed and the
CA gets cleared and the sense data gets cleared too.

Let's suppose that an iSCSI initiator and target a transacting
SCSI business over the world wide internet.  There is only one
initiator (and one target and one LUN) in this example.  The
initiator's commands are getting bounced from Boise to Bangkok
to the target in Moscow and vice versa.  So, there's a noticeable
latency in the iSCSI link and the initiator (who's doing this
gigantic database update, for reasons that I cannot easily
justify) is trying to make up for the latency by pumping
commands in to the network as fast as it can.

In this situation there are dozens of commands in flight from
the initiator to the target at any given instant.  At the instant
the CA condition is set in the target by the unit attention
condition, the initiator has say 9 commands that have been sent
but have not yet reached the target.  The first of these will
clear the CA and return to the initiator with a CHECK CONDITION
status.  The remaining 8 will be processed as if nothing happened.

CA works only on the parallel SCSI bus.  Once upon a time, the
protocol for the parallel SCSI bus was called the 'interlocked'
protocol because the initiator and target march through the
transfers necessary to move data in lock step.  CA takes
advantage the interlocked parallel SCSI bus.  Proper functioning
of CA requires that the initiator know that it is getting a
CHECK CONDITION status before it has any chance to send another
command.  CA cannot work when the initiator and target are not
transferring commands, data and status in lock step.

} Without it [CA] - even with autosense - state synchronization
} in the OS becomes tricky.

My personal opinion is that state synchronization issues should
be eliminated by requiring the target to fully process conditions
before reporting them.  Most unit attention events can be resolved
at the target before they are reported to the initiator.

For the rarely occurring rest, I'd recommend requiring the target
to break its link (connection, whatever, I have trouble with IETF
terms) with the initiator.  That will force the initiator to login
again and thus verify that the changed operating conditions are
valid.  The 'volume change' case mentioned above clearly falls
in the latter category, since the connection that existed before
the volume change might not be allowed to form after the change.

} Perhaps somebody on the list active also in T10 can give us
} a hint of how this type of sequence will be handled without CA.

The other possibility is ACA (see the discussion with Douglas
Otis).  However, I feel that ACA is a very large hammer to be
wielding at otherwise small gnats.

} I understand that CA can be kept even with autosense and we
} can remove the bit but what if T10 decides to keep both?

T10 decides to keep both in the SCSI Architecture because T10
still has the interlocked protocol to support on the parallel
SCSI bus.  When T10 invents a non-interlocked or packetized
protocol for a network-like transport (e.g., FCP), T10 dumps
CA overboard.

Thanks.

Ralph Weber
ENDL Texas