Re: iSCSI Autosense

[Ralph Weber <ralphoweber@compuserve.com>]

Julo,

} How are volume change events supposed to be treated with CA,
} ACA and autosense...<snip>

There are two ways to report a Unit Attention condition:

  1) Asynchronous Event Reporting
  2) Use of a Unit Attention CHECK CONDITION

Asynchronous Event Reporting is optional for both targets and
initiators, and must be enabled by the initiator via the Control
mode page before it can be used.  I have assumed that 3.6 in
draft-satran-iscsi-01.txt is somehow related to AER, and have
yet to work through the details.

The use of a Unit Attention CHECK CONDITION follows all the
same rules as any other CHECK CONDITION with respect to CA,
Autosense, and ACA.  When this mechanism is used (which is
far and away the most common case), there are no functional
differences between a Unit Attention CHECK CONDITION and a
Hardware Error CHECK CONDITION.

I'll provide detailed answers to detailed questions, but the
above information seems like about all that can be said in
response to the question raised.

}<snip> (or for that matter any Async. Event that intends
} to convey to an initiator state information that the initiator
} should be aware of before sending commands - i.e. how is state
} sync. achieved)?

I believe that the vast majority of asynchronous events do
not require the initiator to be aware of them before other
commands are sent.  That is, I believe that 'volume change'
is the exception not the rule and somebody is going to have
to produce a substantial list of exceptions before I'm likely
to change my opinion.

If indeed 'volume change' is the exception, then I have no
problems with according it exceptional handling, as in
forcing logouts (or whatever is equivalent) for all initiators
as a response.

} I was under the impression that this is one of vestigial uses
} of CA.

I believe that the impression is incorrect and I have explained
at great length why CA offers not even a fig leaf's worth of
protection.  I regret that I cannot argue against this incorrect
impression any more forcefully than I already have.

} It is obvious that autosense is fine but until I can't(sic) be
} convinced that it is completely orthogonal to CA use (or to some
} other mechanism that can assure state sync) I would be reluctant
} to force it.

CA is NOT orthogonal to Autosense.  They are two mechanisms for
achieving the same end, which is to ensure that the sense data
for a CHECK CONDITION reaches the initiator.  However, CA is
based on assumptions that apply ONLY to the interlocked parallel
SCSI bus.  Therefore, the only mechanism that is available to
a packetized protocol is Autosense.

Combining CA with a packetized protocol does not improve reliability
or state synchronization between initiator and target.  Exactly the
opposite is true, CA depends for is proper operation on a level of
state synchronization between initiator and target that is available
ONLY on the interlocked parallel SCSI bus.  Combining CA with a
packetized protocol presents a fictitious image of synchronization,
that's all it does.

} If state sync. is provided by some other means that I will be happy
} to oblige and assume autosense is always there.

ACA provides state synchronization between initiators and targets
and I have not contested support for ACA in iSCSI.  In fact, as
you can see from my response this morning to Douglas Otis, I have
reviewed the ACA support provisions in the iSCSI draft and verified
that they are appropriate.

I submit that ACA is the 'other means' that you have requested.

Thanks.

Ralph Weber
ENDL Texas