IBM's response to 12-405r0 SAM-5: UA and task set interaction claraification

[Kevin D Butt]

Formatted message: <a href="http://www.t10.org/cgi-bin/ac.pl?t=r&f=r1211061_f.htm">HTML-formatted message</a>

Fred,
Please see our responses in red.
Kevin D. Butt
SCSI & Fibre Channel Architect, Tape Firmware
Data Protection & Retention
MS 6TYA, 9000 S. Rita Rd., Tucson, AZ 85744
Tel: 520-799-5280
Fax: 520-799-2723 (T/L:321)
Email address: kdbutt at us.ibm.com
http://www-03.ibm.com/servers/storage/ 
From:	"Knight, Frederick" <Frederick.Knight at netapp.com>
To:	Kevin D Butt/Tucson/IBM at IBMUS, 
Date:	10/17/2012 11:40 AM
Subject:	RE: IBM's response to 12-405r0 SAM-5: UA and task set 
interaction claraification
I honestly don?t understand some of your comments.  My questions are 
below:
From: owner-t10 at t10.org [mailto:owner-t10 at t10.org] On Behalf Of Kevin D 
Butt
Sent: Monday, October 15, 2012 7:47 PM
To: T10 Reflector; James P Allen
Subject: IBM's response to 12-405r0 SAM-5: UA and task set interaction 
claraification
IBM has comments related to 12-405r0 
SAM-5: UA and task set interaction claraification
(by: Frederick Knight)
T10/12-405r0   Uploaded: 2012/10/08   175917 bytes
http://www.t10.org/cgi-bin/ac.pl?t=d&f=12-405r0.pdf
The current SCSI standard can be interpreted in multiple ways for UA 
29/00. IBM would agree that clarification might be useful here providing 
we can agree on what that should be. However IBM does not think that 
clarification should be the current proposal in 12-405r0. 
Under this proposal if a lun has a UA 29/00 pending, multiple tasks would 
be allowed to be accepted by that lun. The first task processed (enabled) 
would fail with UA 29/00. The subsequent ones would be governed by QErr 
bit settings.
Actually, that is nothing new in this proposal.  That statement is already 
true.
IBM doesn't agree with this. There appears to be ambiguity in the standard 
on how/when tasks are placed in the task set in relation to pending 
errors.  In SAM section 5.4.2.3 (SCSI Command Received SCSI transport 
protocol service indication) it specifies the task router passes a task to 
the task manager via SCSI Command Received interface. This interface only 
allows one task at a time to passed to the task manager. There is not an 
interface to pass multiple tasks at once to the task manager. Thus the 
task router must call the SCSI Command Received for each task it sends to 
the task manager. The task router needs to wait for the SCSI Command 
Received to complete before it can send another task to the task manager 
via the SCSI Command Received. From section 8.8 (Command state 
transitions) one would infer the task received by the task manager from 
the SCSI command Received interface would go immediately into the dormant 
state. However in the case in point (a Unit Attention 29/00 pending with 
no other tasks in the task set), one could also infer that this task does 
the S1:S2 transition immediately after it goes into the dormant state. 
When that happens it should do the S2:S4 transition immediately.  
Thus the ambiguity in the standard is what the relation between SCSI 
Command Received (of section 5.6) and command state transition (of section 
8.8) when the task set is empty. Does it ever complete the full state 
transition (when pending errors exist for empty task set) before the SCSI 
Command Receive returns to the task router. This goes to the larger 
question of whether it is possible for multiple commands can be accepted 
into the task set before any of them are completed/aborted with Unit 
Attention 29/00.
If the SCSI Command Received led to an immediate Command Aborted in the 
Unit Attention 29/00. Any subsequent task issued by the task router would 
then be governed by QErr and NACA.
While the update to section 5.14 does not say explicit rule out the IBM 
Initiator preferred interpretation (i.e SCSI Command Received for empty 
task set results in immediate Unit Attention 29/00 before other task can 
be issued by the task router to the task manager), it gives greater 
credibility/emphasis on an alternate interpretation.  Future SCSI updates 
could then leverage this update as way to clarify the above ambiguity to 
the alternate interpretation.
This seems problematic for a number of situations where a device's state 
may have substantially changed thus compromising data from the initiator 
perspective. Thus the subsequent tasks may be processed from a device that 
is in a questionable state (i.e. loss of reservations and thus no 
synchronization of read/writes with other hosts, difference in mode 
settings etc). 
What you have described is how QERR=00b works.	If QERR is set to 00b then 
if ACA is being used, everything stops to wait for the host to do whatever 
it wants for cleanup/recovery and if ACA is not being used, then 
everything just proceeds (with all the problems you?ve mentioned).  There 
is nothing in this proposal that changes that operation.  So, I don?t 
understand why this is a problem?
See above description of SAM ambiguity.  The standards ambiguity is beyond 
the semantics of QErr.	
A way to avoid the above issue would be to have the device support QErr = 
x1 settings. This though is problematic, since a device may not support 
this setting.
QERR=x1 is just a way to control where cleanup/recovery actions take place 
(QERR=x1 means the device server does the cleanup and QERR=x0 means the 
host does the cleanup).  And, BTW ? everything described in the proposal 
will still occur.  AFTER the cleanup finishes (it does not matter what 
QERR is set to; no matter who does the cleanup), the UA 29/00 will still 
be queued for OTHER initiators, and so when those initiators finally have 
the UA delivered, it no longer reflects the current state of the device 
(which is all that this proposal is describing).  UAs do not describe a 
current state; they are an indication of a previous event.
As mentioned above QErr=x1 does not clarify the above ambiguity it just 
works around the issue.
A more robust solution (from the initiator's perspective) is for the first 
command to be failed immediately with UA 29/00 before other commands are 
accepted. The subsequent commands would then be governed by whether the 
faulted command had the NACA=1 bit set. If so then subsequent commands 
would be failed with ACA ACTIVE status. This is how some of IBM's 
engineers interpret the standard. Based on how SCSI evolved, IBM thinks 
that this is more consistent with the original intent of the standard. 
Thanks, 
Kevin D. Butt
SCSI & Fibre Channel Architect, Tape Firmware
Data Protection & Retention
MS 6TYA, 9000 S. Rita Rd., Tucson, AZ 85744
Tel: 520-799-5280
Fax: 520-799-2723 (T/L:321)
Email address: kdbutt at us.ibm.com
http://www-03.ibm.com/servers/storage/