From Ralph.Weber at wdc.com  Thu May  1 08:07:14 2014
From: Ralph.Weber at wdc.com (Ralph Weber)
Date: Thu, 1 May 2014 15:07:14 +0000
Subject: Revision 8 of ZBC Commands document uploaded
Message-ID: <mailman.211.1441607400.22532.t10@sandbox.t10.org>

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

Curtis has been waylaid by an unplanned significant family event.
So, Gerry Houlder and I have put our heads together in an attempt to recreate
all the changes that the Monday 28 April call wanted to see included in
14-010r8. We thing we got to within 10% of the finish line.
We also tripped over a couple of new posers which have been documented in
editor's notes.
The result can be downloaded from:
http://www.t10.org/cgi-bin/ac.pl?t=d&f=14-010r8.pdf
Thank you Gerry for you help.
See you all in Vancouver,
.Ralph


From Ralph.Weber at wdc.com  Thu May  1 08:16:46 2014
From: Ralph.Weber at wdc.com (Ralph Weber)
Date: Thu, 1 May 2014 15:16:46 +0000
Subject: SPC-4 letter ballot files
Message-ID: <mailman.212.1441607400.22532.t10@sandbox.t10.org>

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

A new file has joined the usual cast of characters in the SPC-4 Letter Ballot
lineup. In 1.5 pithy pages, it summarizes all the changes between SPC-4 r36s
and SPC-4 r36t.
http://www.t10.org/cgi-bin/ac.pl?t=d&f=14-123r0.pdf
Suffice to say, the first public review for SPC-4 is just around the corner.
As always, five files are needed to see the full SPC-4 Letter Ballot picture.
The comments database in PDF form:
http://www.t10.org/cgi-bin/ac.pl?t=d&f=13-256r8.pdf
A supplement to the comments database:
http://www.t10.org/cgi-bin/ac.pl?t=d&f=13-070r8.pdf
The latest SPC-4 revision:
http://www.t10.org/cgi-bin/ac.pl?t=f&f=spc4r36t.pdf
The comments database in FDF format:
http://www.t10.org/cgi-bin/ac.pl?t=d&f=13-256r8.fdf
The SPC-4 revision into which the FDF file must be imported:
http://www.t10.org/cgi-bin/ac.pl?t=f&f=spc4r36.pdf
Let the good times roll in Vancouver,
.Ralph


From lohmeyer at t10.org  Sat May  3 23:01:52 2014
From: lohmeyer at t10.org (T10 Document Administrator)
Date: Sun, 4 May 2014 00:01:52 -0600
Subject: Recent T10 documents uploaded since 2014/04/27
Message-ID: <mailman.213.1441607400.22532.t10@sandbox.t10.org>

* From the T10 Reflector (t10 at t10.org), posted by:
* T10 Document Administrator <lohmeyer at t10.org>
*
Proposals
---------
SBC-4 Add Force bit to UNMAP
(by: Rob Elliott, Curtis Ballard)
T10/13-054r3   Uploaded: 2014/05/02   138100 bytes
http://www.t10.org/cgi-bin/ac.pl?t=d&f=13-054r3.pdf
SPC-4 Letter Ballot Comment Resolutions
(by: Ralph Weber)
T10/13-256r8   Uploaded: 2014/05/01   9055830 bytes
http://www.t10.org/cgi-bin/ac.pl?t=d&f=13-256r8.fdf
SPC-4 Letter Ballot Comment Resolutions
(by: Ralph Weber)
T10/13-256r8   Uploaded: 2014/05/01   5410787 bytes
http://www.t10.org/cgi-bin/ac.pl?t=d&f=13-256r8.pdf
ZBC host aware model clauses for write and read commands
(by: Gerald Houlder)
T10/14-007r9   Uploaded: 2014/04/28   83364 bytes
http://www.t10.org/cgi-bin/ac.pl?t=d&f=14-007r9.pdf
ZBC Proposed Commands
(by: Curtis Stevens)
T10/14-010r8   Uploaded: 2014/05/01   195946 bytes
http://www.t10.org/cgi-bin/ac.pl?t=d&f=14-010r8.pdf
ZBC common model references (clause 4)
(by: Gerald Houlder)
T10/14-025r4   Uploaded: 2014/04/28   49701 bytes
http://www.t10.org/cgi-bin/ac.pl?t=d&f=14-025r4.pdf
SAT-3 LB: Power Condition mode page cleanup
(by: Ralph Weber)
T10/14-106r0   Uploaded: 2014/04/29   343642 bytes
http://www.t10.org/cgi-bin/ac.pl?t=d&f=14-106r0.pdf
SAM-5 SBC-4 SPC-5  Command Deadlines
(by: Paul Suhler)
T10/14-107r0   Uploaded: 2014/05/02   548535 bytes
http://www.t10.org/cgi-bin/ac.pl?t=d&f=14-107r0.pdf
T11 Liaison Report April 2014
(by: Steven Wilson)
T10/14-116r0   Uploaded: 2014/04/28   82360 bytes
http://www.t10.org/cgi-bin/ac.pl?t=d&f=14-116r0.pdf
SPL4: Maximum allowed XFER_RDYs
(by: William Martin)
T10/14-120r0   Uploaded: 2014/04/29   156177 bytes
http://www.t10.org/cgi-bin/ac.pl?t=d&f=14-120r0.pdf
SPC-5: Clarification of Download Microcode mode 0Dh
(by: William Martin)
T10/14-121r0   Uploaded: 2014/04/29   123028 bytes
http://www.t10.org/cgi-bin/ac.pl?t=d&f=14-121r0.pdf
Elaboration of Style Guide Hyphenation spec
(by: Ralph Weber)
T10/14-122r0   Uploaded: 2014/04/30   105437 bytes
http://www.t10.org/cgi-bin/ac.pl?t=d&f=14-122r0.pdf
Letter Ballot changes in SPC-4 r36t
(by: Ralph Weber)
T10/14-123r0   Uploaded: 2014/05/01   92470 bytes
http://www.t10.org/cgi-bin/ac.pl?t=d&f=14-123r0.pdf
SAS4 FEC options
(by: Graeme Boyd)
T10/14-124r0   Uploaded: 2014/05/02   3380308 bytes
http://www.t10.org/cgi-bin/ac.pl?t=d&f=14-124r0.pdf
SBC-4 Add skip mask command support bit in VPD page B1h
(by: Gerald Houlder)
T10/14-126r0   Uploaded: 2014/05/02   33265 bytes
http://www.t10.org/cgi-bin/ac.pl?t=d&f=14-126r0.pdf
SBC-4 Unmap methods and text clarifications
(by: Curtis Ballard, Rob Elliott)
T10/14-128r0   Uploaded: 2014/05/02   143335 bytes
http://www.t10.org/cgi-bin/ac.pl?t=d&f=14-128r0.pdf
SAS-4/SPL-4 Primitive Format
(by: Bill Voorhees, Harvey Newman)
T10/14-129r0   Uploaded: 2014/05/02   1180643 bytes
http://www.t10.org/cgi-bin/ac.pl?t=d&f=14-129r0.pdf
Working Drafts
--------------
SCSI Primary Commands - 4 (SPC-4)
(Editor: Ralph Weber)
 Rev: 36t      Uploaded: 2014/05/01   4613489 bytes
http://www.t10.org/cgi-bin/ac.pl?t=f&f=spc4r36t.pdf
(Report generated on 2014/05/04 at 00:01:51)
*
* For T10 Reflector information, send a message with
* 'info t10' (no quotes) in the message body to majordomo at t10.org


From lohmeyer at t10.org  Mon May  5 14:19:53 2014
From: lohmeyer at t10.org (John Lohmeyer)
Date: Mon, 05 May 2014 15:19:53 -0600
Subject: Draft Joint SAS Protocol / PHY working group minutes posted
Message-ID: <mailman.214.1441607400.22532.t10@sandbox.t10.org>

* From the T10 Reflector (t10 at t10.org), posted by:
* John Lohmeyer <lohmeyer at t10.org>
*
The draft minutes of the Joint SAS Protocol / PHY working group meeting are
available at:
  http://www.t10.org/cgi-bin/ac.pl?t=d&f=14-117r0.htm
--
John Lohmeyer		       Email: lohmeyer at t10.org
LSI Corp.		       Voice: +1-719-533-7560
4420 ArrowsWest Dr.		Cell: +1-719-338-1642
Colo Spgs, CO 80907
*
* For T10 Reflector information, send a message with
* 'info t10' (no quotes) in the message body to majordomo at t10.org


From Ralph.Weber at wdc.com  Mon May  5 20:32:19 2014
From: Ralph.Weber at wdc.com (Ralph Weber)
Date: Tue, 6 May 2014 03:32:19 +0000
Subject: ZBC roll-up document posted
Message-ID: <mailman.215.1441607400.22532.t10@sandbox.t10.org>

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

A document that rolls approved and nearly approved ZBC proposals into a
properly linked whole has been posted:
http://www.t10.org/cgi-bin/ac.pl?t=d&f=14-125r0.pdf
The approved proposals in 14-125r0 are:
  *   14-007r9 ? ZBC definitions and model clauses
  *   14-015r2 ? ZBC parameters (clause 6)
  *   14-025r4 ? ZBC common model references (clause 4)
The nearly approved proposals in 14-125r0 are:
  *   14-009r6 ? ZBC model clauses for zone types
[14-009r7 recommended but not available]
  *   14-010r8 ? ZBC Proposed Commands
[close, but no cigar in the recommendation column]
[nonetheless, necessary for completeness]
All the best,
.Ralph


From lohmeyer at t10.org  Wed May  7 11:40:16 2014
From: lohmeyer at t10.org (John Lohmeyer)
Date: Wed, 07 May 2014 12:40:16 -0600
Subject: test T10 reflector
Message-ID: <mailman.216.1441607400.22532.t10@sandbox.t10.org>

* From the T10 Reflector (t10 at t10.org), posted by:
* John Lohmeyer <lohmeyer at t10.org>
*
please ignore.
--
John Lohmeyer		       Email: lohmeyer at t10.org
Avago Technologies	       Voice: +1-719-533-7560
4420 ArrowsWest Dr.		Cell: +1-719-338-1642
Colo Spgs, CO 80907
*
* For T10 Reflector information, send a message with
* 'info t10' (no quotes) in the message body to majordomo at t10.org


From Ralph.Weber at wdc.com  Wed May  7 21:40:45 2014
From: Ralph.Weber at wdc.com (Ralph Weber)
Date: Thu, 8 May 2014 04:40:45 +0000
Subject: r1 of ZBC documents rollup posted
Message-ID: <mailman.217.1441607400.22532.t10@sandbox.t10.org>

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

I have come into possession of the 14-009 and 14-010 markups from the 24
April face-to-face gathering.
As a result, the temptation has been too much to bear. There was no choice
except to turn a revision of 14-125 with all the recommended changes included
(the Kitchen Sink revision, if you will).
For all the details, see:
http://www.t10.org/cgi-bin/ac.pl?t=d&f=14-125r1.pdf
All the best,
.Ralph


From alvin.cox at seagate.com  Wed May  7 23:17:36 2014
From: alvin.cox at seagate.com (Alvin Cox)
Date: Thu, 8 May 2014 01:17:36 -0500
Subject: SAS-4 PHY teleconference, 10:00 am CDT, Thursday June 5, 2014
Message-ID: <mailman.218.1441607400.22532.t10@sandbox.t10.org>

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

Agenda TBD:
Error correction
Coupling capacitors
Connector performance
Other topics
Topic: SAS 4 PHY
Date: Thursday, June 5, 2014
Time: 10:00 am, Central Daylight Time (Chicago, GMT-05:00)
Meeting Number: 825 947 037
Meeting Password: SAS4Phycall
-------------------------------------------------------
To join the online meeting (Now from mobile devices!)
-------------------------------------------------------
1. Go to


From david.black at emc.com  Sat May 10 16:15:33 2014
From: david.black at emc.com (Black, David)
Date: Sat, 10 May 2014 19:15:33 -0400
Subject: T10: Logical Unit Conglomerates call [May]
Message-ID: <mailman.219.1441607401.22532.t10@sandbox.t10.org>

Formatted message: <a href="http://www.t10.org/cgi-bin/ac.pl?t=r&f=r1405100_f.htm">HTML-formatted message</a>
Attachment #1: <a href="http://www.t10.org/cgi-bin/ac.pl?t=r&f=r1405100_nameless-204-3.txt">nameless-204-3.txt</a>

Wed, May 28, 2014, 12n-2p Pacific
Proposals: Latest versions of 13-264 and 13-002.
David Black invites you to an online meeting using WebEx.
Meeting Number: 644 750 615
Meeting Password: LU-cong-iyxw3
-------------------------------------------------------
To join this meeting (Now from mobile devices!)
-------------------------------------------------------
1. Go to https://emccorp.webex.com/emccorp/j.php?J=644750615&PW=NZDliNjUwZTY4
2. If requested, enter your name and email address.
3. If a password is required, enter the meeting password: LU-cong-iyxw3
4. Click "Join".
5. Follow the instructions that appear on your screen.
-------------------------------------------------------
Teleconference information
-------------------------------------------------------
Provide your phone number when you join the meeting to receive a call back.
Alternatively, you can call:
Call-in toll-free number: 1-888-6433084  (US)
Call-in number: 1-857-2074204  (US)
Show global numbers:
Attendee access code: 122 099 67
To view a full list of global access numbers, click here:
http://www.emcconferencing.com/emc/globalaccess/
http://www.webex.com
IMPORTANT NOTICE: This WebEx service includes a feature that allows audio and
any documents and other materials exchanged or viewed during the session to
be recorded. By joining this session, you automatically consent to such
recordings. If you do not consent to the recording, discuss your concerns
with the meeting host prior to the start of the recording or do not join the
session. Please note that any such recordings may be subject to discovery in
the event of litigation.


From david.black at emc.com  Sat May 10 16:15:42 2014
From: david.black at emc.com (Black, David)
Date: Sat, 10 May 2014 19:15:42 -0400
Subject: T10: Logical Unit Conglomerates call [June]
Message-ID: <mailman.220.1441607401.22532.t10@sandbox.t10.org>

Formatted message: <a href="http://www.t10.org/cgi-bin/ac.pl?t=r&f=r1405101_f.htm">HTML-formatted message</a>
Attachment #1: <a href="http://www.t10.org/cgi-bin/ac.pl?t=r&f=r1405101_nameless-204-6.txt">nameless-204-6.txt</a>

Wed, June 25, 2014, 12n-2p Pacific
Proposals: Latest versions of 13-264 and 13-002.
David Black invites you to an online meeting using WebEx.
Meeting Number: 642 059 312
Meeting Password: LU-cong-xdej2
-------------------------------------------------------
To join this meeting (Now from mobile devices!)
-------------------------------------------------------
1. Go to https://emccorp.webex.com/emccorp/j.php?J=642059312&PW=NNWMzNTdkYzA2
2. If requested, enter your name and email address.
3. If a password is required, enter the meeting password: LU-cong-xdej2
4. Click "Join".
5. Follow the instructions that appear on your screen.
-------------------------------------------------------
Teleconference information
-------------------------------------------------------
Provide your phone number when you join the meeting to receive a call back.
Alternatively, you can call:
Call-in toll-free number: 1-888-6433084  (US)
Call-in number: 1-857-2074204  (US)
Show global numbers:
Attendee access code: 122 099 67
To view a full list of global access numbers, click here:
http://www.emcconferencing.com/emc/globalaccess/
http://www.webex.com
IMPORTANT NOTICE: This WebEx service includes a feature that allows audio and
any documents and other materials exchanged or viewed during the session to
be recorded. By joining this session, you automatically consent to such
recordings. If you do not consent to the recording, discuss your concerns
with the meeting host prior to the start of the recording or do not join the
session. Please note that any such recordings may be subject to discovery in
the event of litigation.


From lohmeyer at t10.org  Sat May 10 23:01:52 2014
From: lohmeyer at t10.org (T10 Document Administrator)
Date: Sun, 11 May 2014 00:01:52 -0600
Subject: Recent T10 documents uploaded since 2014/05/04
Message-ID: <mailman.221.1441607401.22532.t10@sandbox.t10.org>

* From the T10 Reflector (t10 at t10.org), posted by:
* T10 Document Administrator <lohmeyer at t10.org>
*
Proposals
---------
SPC-5: Device Internal Status Dump
(by: Frederick Knight)
T10/13-029r3   Uploaded: 2014/05/04   261256 bytes
http://www.t10.org/cgi-bin/ac.pl?t=d&f=13-029r3.pdf
SPC-5 Add more environment parameters to Temperature log page
(by: Gerald Houlder)
T10/13-253r4   Uploaded: 2014/05/08   118909 bytes
http://www.t10.org/cgi-bin/ac.pl?t=d&f=13-253r4.pdf
SSC-5: Recommended Access Order
(by: Kevin Butt)
T10/13-266r5   Uploaded: 2014/05/06   126833 bytes
http://www.t10.org/cgi-bin/ac.pl?t=d&f=13-266r5.pdf
SAS4 SPL-4 Packet format
(by: Tim Symons)
T10/13-268r2   Uploaded: 2014/05/05   250896 bytes
http://www.t10.org/cgi-bin/ac.pl?t=d&f=13-268r2.pdf
ZBC Proposed Commands
(by: Curtis Stevens)
T10/14-010r9   Uploaded: 2014/05/08   69630 bytes
http://www.t10.org/cgi-bin/ac.pl?t=d&f=14-010r9.pdf
PQI-2 - Interrupt mode and polled mode clarification
(by: Ie-Wei Njoo)
T10/14-026r2   Uploaded: 2014/05/07   553278 bytes
http://www.t10.org/cgi-bin/ac.pl?t=d&f=14-026r2.pdf
SBC-4 SPC-5 Atomic writes and reads
(by: Martin, Knight, Ballard)
T10/14-043r4   Uploaded: 2014/05/07   362302 bytes
http://www.t10.org/cgi-bin/ac.pl?t=d&f=14-043r4.pdf
T13 Liaison Report
(by: Dan Colegrove)
T10/14-044r2   Uploaded: 2014/05/08   13230 bytes
http://www.t10.org/cgi-bin/ac.pl?t=d&f=14-044r2.pdf
T13 Liaison Report
(by: Dan Colegrove)
T10/14-044r2   Uploaded: 2014/05/08   105472 bytes
http://www.t10.org/cgi-bin/ac.pl?t=d&f=14-044r2.ppt
Channel requests and important parameters
(by: Mickey Felton)
T10/14-072r2   Uploaded: 2014/05/05   543137 bytes
http://www.t10.org/cgi-bin/ac.pl?t=d&f=14-072r2.pdf
SBC-4: Designed Utilization VPD data
(by: Ralph Weber)
T10/14-075r1   Uploaded: 2014/05/08   108923 bytes
http://www.t10.org/cgi-bin/ac.pl?t=d&f=14-075r1.pdf
SPL-4 Active transmitter tuning
(by: Tim Symons)
T10/14-077r1   Uploaded: 2014/05/05   101284 bytes
http://www.t10.org/cgi-bin/ac.pl?t=d&f=14-077r1.pdf
ZBC Zoned Block Device VPD page
(by: Gerald Houlder)
T10/14-104r1   Uploaded: 2014/05/08   62490 bytes
http://www.t10.org/cgi-bin/ac.pl?t=d&f=14-104r1.pdf
SFSC: Initial Contents
(by: David Black)
T10/14-114r1   Uploaded: 2014/05/08   22963 bytes
http://www.t10.org/cgi-bin/ac.pl?t=d&f=14-114r1.pdf
SAM-5: REPORT LUNS and administrative logical units
(by: David Black)
T10/14-115r1   Uploaded: 2014/05/08   23208 bytes
http://www.t10.org/cgi-bin/ac.pl?t=d&f=14-115r1.pdf
Minutes of Joint SAS Protocol/PHY WG - May 5, 2014
(by: Weber/Lohmeyer)
T10/14-117r0   Uploaded: 2014/05/05   38247 bytes
http://www.t10.org/cgi-bin/ac.pl?t=d&f=14-117r0.htm
Minutes of Joint SAS Protocol/PHY WG - May 5, 2014
(by: Weber/Lohmeyer)
T10/14-117r0   Uploaded: 2014/05/05   111499 bytes
http://www.t10.org/cgi-bin/ac.pl?t=d&f=14-117r0.pdf
SPL4: Maximum allowed XFER_RDYs
(by: William Martin)
T10/14-120r1   Uploaded: 2014/05/05   156913 bytes
http://www.t10.org/cgi-bin/ac.pl?t=d&f=14-120r1.pdf
SPC-5: Clarification of Download Microcode mode 0Dh
(by: William Martin)
T10/14-121r1   Uploaded: 2014/05/08   124943 bytes
http://www.t10.org/cgi-bin/ac.pl?t=d&f=14-121r1.pdf
ZBC r01 proposals roll up
(by: Curtis Stevens {Ralph Weber})
T10/14-125r0   Uploaded: 2014/05/05   268296 bytes
http://www.t10.org/cgi-bin/ac.pl?t=d&f=14-125r0.pdf
ZBC r01 proposals roll up
(by: Curtis Stevens {Ralph Weber})
T10/14-125r1   Uploaded: 2014/05/07   270879 bytes
http://www.t10.org/cgi-bin/ac.pl?t=d&f=14-125r1.pdf
ZBC r01 proposals roll up
(by: Curtis Stevens {Ralph Weber})
T10/14-125r2   Uploaded: 2014/05/08   272299 bytes
http://www.t10.org/cgi-bin/ac.pl?t=d&f=14-125r2.pdf
SAS-4 Capacitors
(by: Harvey Newman)
T10/14-127r0   Uploaded: 2014/05/06   492550 bytes
http://www.t10.org/cgi-bin/ac.pl?t=d&f=14-127r0.pdf
New ZBC device model
(by: Joe Breher)
T10/14-130r0   Uploaded: 2014/05/06   651504 bytes
http://www.t10.org/cgi-bin/ac.pl?t=d&f=14-130r0.pdf
READ BUFFER(32) and WRITE BUFFER(32)
(by: Joe Breher)
T10/14-131r0   Uploaded: 2014/05/06   726480 bytes
http://www.t10.org/cgi-bin/ac.pl?t=d&f=14-131r0.pdf
Minutes SSC-5 May 05, 2014
(by: Kevin Butt)
T10/14-132r0   Uploaded: 2014/05/06   23035 bytes
http://www.t10.org/cgi-bin/ac.pl?t=d&f=14-132r0.pdf
STA - T10 Liaison Report May 8, 2014
(by: Marty Czekalski)
T10/14-134r0   Uploaded: 2014/05/08   435189 bytes
http://www.t10.org/cgi-bin/ac.pl?t=d&f=14-134r0.pdf
IETF Liaison Report to T10
(by: David Black)
T10/14-135r0   Uploaded: 2014/05/08   464483 bytes
http://www.t10.org/cgi-bin/ac.pl?t=d&f=14-135r0.pdf
SSC-5 Working Group Report to Plenary, May 2014
(by: Curtis Ballard)
T10/14-136r0   Uploaded: 2014/05/08   21857 bytes
http://www.t10.org/cgi-bin/ac.pl?t=d&f=14-136r0.pdf
SNIA Liaison Report May 2014
(by: Frederick Knight)
T10/14-137r0   Uploaded: 2014/05/08   253292 bytes
http://www.t10.org/cgi-bin/ac.pl?t=d&f=14-137r0.pdf
NWIP SAS-3 (14776-154)
(by: Gary Robinson)
T10/14-138r0   Uploaded: 2014/05/08   58590 bytes
http://www.t10.org/cgi-bin/ac.pl?t=d&f=14-138r0.docx
NWIP SAS-3 (14776-154)
(by: Gary Robinson)
T10/14-138r0   Uploaded: 2014/05/08   318554 bytes
http://www.t10.org/cgi-bin/ac.pl?t=d&f=14-138r0.pdf
Working Drafts
--------------
Zoned Block Commands (ZBC)
(Editor: Curtis Stevens)
 Rev: 01       Uploaded: 2014/05/10   232054 bytes
http://www.t10.org/cgi-bin/ac.pl?t=f&f=zbc-r01.pdf
(Report generated on 2014/05/11 at 00:01:52)
*
* For T10 Reflector information, send a message with
* 'info t10' (no quotes) in the message body to majordomo at t10.org


From lohmeyer at t10.org  Sun May 11 13:26:58 2014
From: lohmeyer at t10.org (John Lohmeyer)
Date: Sun, 11 May 2014 14:26:58 -0600
Subject: draft CAP WG minutes posted
Message-ID: <mailman.222.1441607401.22532.t10@sandbox.t10.org>

* From the T10 Reflector (t10 at t10.org), posted by:
* John Lohmeyer <lohmeyer at t10.org>
*
The draft minutes of the CAP working group meeting are available at:
  http://www.t10.org/cgi-bin/ac.pl?t=d&f=14-118r0.htm
--
John Lohmeyer		       Email: lohmeyer at t10.org
Avago Technologies	       Voice: +1-719-533-7560
4420 ArrowsWest Dr.		Cell: +1-719-338-1642
Colo Spgs, CO 80907
*
* For T10 Reflector information, send a message with
* 'info t10' (no quotes) in the message body to majordomo at t10.org


From george.penokie at avagotech.com  Wed May 28 11:12:23 2014
From: george.penokie at avagotech.com (George Penokie)
Date: Wed, 28 May 2014 13:12:23 -0500
Subject: New revision of SAM-5 queuing state machines
Message-ID: <mailman.223.1441607401.22532.t10@sandbox.t10.org>

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

I have posted a new revision of the SAM-5 state machine proposal. This one
includes all the changes needed to SAM-5 to complete the switch to the new
state machine.
Your request to upload a file or files to the T10 site has been accepted.
Your PDF file will be posted at:
   http://www.t10.org/cgi-bin/ac.pl?t=d&f=14-054r3.pdf
Bye for now,
George Penokie
Avago Technologies
3033 41 St NW
Rochester , MN 55901
507-328-9017
george.penokie at avagotech.com


From gerry.houlder at seagate.com  Wed May 28 15:19:08 2014
From: gerry.houlder at seagate.com (Gerry Houlder)
Date: Wed, 28 May 2014 17:19:08 -0500
Subject: Comment on ZBC rev. 01a
Message-ID: <mailman.224.1441607401.22532.t10@sandbox.t10.org>

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

Hi,
I noticed that table 20 has a reference to SAT-3 (there has been discussion
that this should change to SAT-4?) but neither SAT-3 or SAT-4 show up in
the approved references (2.2) or references under development (2.3).
Shouldn't SAT-x be added?


From Neil.Wanamaker at pmcs.com  Wed May 28 15:26:35 2014
From: Neil.Wanamaker at pmcs.com (Neil Wanamaker)
Date: Wed, 28 May 2014 22:26:35 +0000
Subject: SAT-3 LB Comment resolution
Message-ID: <mailman.225.1441607401.22532.t10@sandbox.t10.org>

Attachment #1: <a href="http://www.t10.org/cgi-bin/ac.pl?t=r&f=r1405282_nameless-524-2-1.html">nameless-524-2-1.html</a>
Attachment #2: <a href="http://www.t10.org/cgi-bin/ac.pl?t=r&f=r1405282_nameless-524-3.txt">nameless-524-3.txt</a>

There will be a SAT-3 Letter Ballot Conference call on June 5, 2014, from 1-3
PM PDT.
***DO NOT DELETE OR CHANGE ANY OF THE TEXT BELOW THIS LINE***
Neil Wanamaker has scheduled this WebEx meeting.
When it's time, start or join the WebEx meeting from here:


From david.black at emc.com  Thu May 29 06:55:16 2014
From: david.black at emc.com (Black, David)
Date: Thu, 29 May 2014 09:55:16 -0400
Subject: Additional Logical Unit Conglomerates call - July 9
Message-ID: <mailman.226.1441607401.22532.t10@sandbox.t10.org>

* From the T10 Reflector (t10 at t10.org), posted by:
* "Black, David" <david.black at emc.com>
*
There will be an additional Logical Unit Conglomerates call during
the week before the July T10 meeting.
Logical Unit Conglomerates Wednesday, July 9, 2p-4p Eastern, 11a-1p Pacific.
Details will be posted to the T10 reflector shortly.
Thanks,
--David
----------------------------------------------------
David L. Black, Distinguished Engineer
EMC Corporation, 176 South St., Hopkinton, MA? 01748
+1 (508) 293-7953???????????? FAX: +1 (508) 293-7786
david.black at emc.com??????? Mobile: +1 (978) 394-7754
----------------------------------------------------
*
* For T10 Reflector information, send a message with
* 'info t10' (no quotes) in the message body to majordomo at t10.org


From david.black at emc.com  Thu May 29 07:00:09 2014
From: david.black at emc.com (Black, David)
Date: Thu, 29 May 2014 10:00:09 -0400
Subject: T10: Logical Unit Conglomerates call [July 9]
Message-ID: <mailman.227.1441607401.22532.t10@sandbox.t10.org>

Formatted message: <a href="http://www.t10.org/cgi-bin/ac.pl?t=r&f=r1405291_f.htm">HTML-formatted message</a>
Attachment #1: <a href="http://www.t10.org/cgi-bin/ac.pl?t=r&f=r1405291_nameless-1460-3.txt">nameless-1460-3.txt</a>

Wed, July 9, 2014, 11a-1p Pacific
Proposals: Latest versions of 13-264, 13-002, 14-146.
David Black invites you to an online meeting using WebEx.
Meeting Number: 640 278 891
Meeting Password: T10-cong-68Gq17*
-------------------------------------------------------
To join this meeting (Now from mobile devices!)
-------------------------------------------------------
1. Go to https://emccorp.webex.com/emccorp/j.php?J=640278891&PW=NN2YzN2I2NmM0
2. If requested, enter your name and email address.
3. If a password is required, enter the meeting password: T10-cong-68Gq17*
4. Click "Join".
5. Follow the instructions that appear on your screen.
-------------------------------------------------------
Teleconference information
-------------------------------------------------------
Provide your phone number when you join the meeting to receive a call back.
Alternatively, you can call:
Call-in toll-free number: 1-888-6433084  (US)
Call-in number: 1-857-2074204  (US)
Attendee access code: 122 099 67
To view a full list of global access numbers, click here:
http://www.emcconferencing.com/emc/globalaccess/
http://www.webex.com
IMPORTANT NOTICE: This WebEx service includes a feature that allows audio and
any documents and other materials exchanged or viewed during the session to
be recorded. By joining this session, you automatically consent to such
recordings. If you do not consent to the recording, discuss your concerns
with the meeting host prior to the start of the recording or do not join the
session. Please note that any such recordings may be subject to discovery in
the event of litigation.


From Paul.Suhler at hgst.com  Thu May 29 09:30:50 2014
From: Paul.Suhler at hgst.com (Paul Suhler)
Date: Thu, 29 May 2014 16:30:50 +0000
Subject: More: SAM-5 Command Timeout Subproposal for 14-107
Message-ID: <mailman.228.1441607401.22532.t10@sandbox.t10.org>

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

Okay, that attempt to provoke the lions' den did not evoke any roars, so it
must have been acceptable, n'est pas?  So, here's another try:
The previously-posted revision specified when a command timeout occurs.  I
now propose to implement the timeout into the state machines by stating that
when a timeout occurs, the device server sends a (newly-defined) Time Out
Command message to the appropriate set of LU_CS states.  And I'll define the
resulting behaviors.
Thanks,
Paul
From: owner-t10 at t10.org [mailto:owner-t10 at t10.org] On Behalf Of Paul Suhler
Sent: Wednesday, May 28, 2014 4:01 PM
To: T10 E-mail Reflector (t10 at t10.org)
Subject: SAM-5 Command Timeout Subproposal for 14-107
Hi, George (and anyone else who wishes to comment).
As suggested in CAP in May, I'm trying to leverage the new state machines in
14-054 for defining the command deadline operations.  For example, in order
to record the arrival time of a command and set its expiration time, I want
to abandon adding an argument to the Route Command operation and instead hang
it on a newly-defined transition.  Using 14-054r3 as a base, I propose to add
the paragraph in blue:
8.9.4.2 LU_CS1:Idle state
8.9.4.2.1 LU_CS1:Idle state description
This is the initial state of the LU_CS state machine.
8.9.4.2.2 Transition LU_CS1:Idle to LU_CS2:Dormant
This transition shall occur after receiving:
a) a Queue Command message with a Task Attribute argument set to Simple; or
b) a Queue Command message with a Task Attribute argument set to Ordered.
This transition shall include the following arguments:
a) I_T_L_Q Nexus;
b) CDB;
c) Task Attribute;
d) CRN, if any;
e) Command Priority, if any; and
f) First Burst Enabled, if any.
If this transition occurred after receiving a Queue Command message with a
Task Attribute set to simple, then the Deadline Expiration time attribute of
this command shall be set as specified in 8.7.2.2.
The new subclause 8.7.2.2 relies upon the proposed command deadline clock,
which is in the logical unit, and upon a command deadline value in the
proposed Command Deadline mode page.
Any problems with specifying this behavior here?  Other questions?
Thanks,
Paul
Paul A. Suhler, PhD
Research Staff Member
HGST Research
paul.suhler at hgst.com
o: 949-476-1180 x275448
m: 949-241-6443
3001 Daimler St.
Santa Ana, CA 92705-5812
www.hgst.com<<a href="http://www.hgst.com/&gt">http://www.hgst.com/&gt;


From Paul.Suhler at hgst.com  Fri May 30 10:07:43 2014
From: Paul.Suhler at hgst.com (Paul Suhler)
Date: Fri, 30 May 2014 17:07:43 +0000
Subject: Yet Another SAM-5 Command Timeout Subproposal for 14-107
Message-ID: <mailman.229.1441607401.22532.t10@sandbox.t10.org>

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

It's been suggested to me that the lack of a roar is because the lion sleeps
Wednesday night through Sunday night.
I'd like to check my understanding of 14-054r3 and how that affects my
proposal:
My intent is that a command may time out any time after arrival and before it
first requests a data transfer.  In terms of T10/14-054r3, this corresponds
to command states LU_CS2:Dormant and LU_CS3:Enabled.  The expiration time is
computed when the command first arrives, as indicated by entry into
LU_CS2:Dormant; this assumes that four events take place essentially at the
same time, given adequate resources:
a)	      Arrival of the command at the SCSI Target Port.
b)	      Arrival at the TM of the SCSI Command Received message.
c)	      Arrival at the CS of the Queue Command message.
d)	      Entry into LU_CS2:Dormant.
Is that assumption correct?
I'd like not to introduce a new message.  Having specified in the model
section the conditions upon which a timeout happens, can I just specify in
the descriptions for LU_CS2 and LU_CS3 what happens when the timeout occurs? 
This would be analogous to the description of the LU_DS state, which
specifies what happens when an error occurs during command processing
Or is a message to those states necessary?
Thanks,
Paul
From: owner-t10 at t10.org [mailto:owner-t10 at t10.org] On Behalf Of Paul Suhler
Sent: Thursday, May 29, 2014 9:31 AM
To: T10 E-mail Reflector (t10 at t10.org)
Subject: More: SAM-5 Command Timeout Subproposal for 14-107
Okay, that attempt to provoke the lions' den did not evoke any roars, so it
must have been acceptable, n'est pas?  So, here's another try:
The previously-posted revision specified when a command timeout occurs.  I
now propose to implement the timeout into the state machines by stating that
when a timeout occurs, the device server sends a (newly-defined) Time Out
Command message to the appropriate set of LU_CS states.  And I'll define the
resulting behaviors.
Thanks,
Paul
From: owner-t10 at t10.org<mailto:owner-t10 at t10.org> [mailto:owner-t10 at t10.org]
On Behalf Of Paul Suhler
Sent: Wednesday, May 28, 2014 4:01 PM
To: T10 E-mail Reflector (t10 at t10.org<mailto:t10 at t10.org>)
Subject: SAM-5 Command Timeout Subproposal for 14-107
Hi, George (and anyone else who wishes to comment).
As suggested in CAP in May, I'm trying to leverage the new state machines in
14-054 for defining the command deadline operations.  For example, in order
to record the arrival time of a command and set its expiration time, I want
to abandon adding an argument to the Route Command operation and instead hang
it on a newly-defined transition.  Using 14-054r3 as a base, I propose to add
the paragraph in blue:
8.9.4.2 LU_CS1:Idle state
8.9.4.2.1 LU_CS1:Idle state description
This is the initial state of the LU_CS state machine.
8.9.4.2.2 Transition LU_CS1:Idle to LU_CS2:Dormant
This transition shall occur after receiving:
a) a Queue Command message with a Task Attribute argument set to Simple; or
b) a Queue Command message with a Task Attribute argument set to Ordered.
This transition shall include the following arguments:
a) I_T_L_Q Nexus;
b) CDB;
c) Task Attribute;
d) CRN, if any;
e) Command Priority, if any; and
f) First Burst Enabled, if any.
If this transition occurred after receiving a Queue Command message with a
Task Attribute set to simple, then the Deadline Expiration time attribute of
this command shall be set as specified in 8.7.2.2.
The new subclause 8.7.2.2 relies upon the proposed command deadline clock,
which is in the logical unit, and upon a command deadline value in the
proposed Command Deadline mode page.
Any problems with specifying this behavior here?  Other questions?
Thanks,
Paul
Paul A. Suhler, PhD
Research Staff Member
HGST Research
paul.suhler at hgst.com
o: 949-476-1180 x275448
m: 949-241-6443
3001 Daimler St.
Santa Ana, CA 92705-5812
www.hgst.com<<a href="http://www.hgst.com/&gt">http://www.hgst.com/&gt;


From gerry.houlder at seagate.com  Fri May 30 10:42:52 2014
From: gerry.houlder at seagate.com (Gerry Houlder)
Date: Fri, 30 May 2014 12:42:52 -0500
Subject: Yet Another SAM-5 Command Timeout Subproposal for 14-107
Message-ID: <mailman.230.1441607401.22532.t10@sandbox.t10.org>

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

It seems reasonable to me that the arrival at the CS of a Queue Command
message (item c) is a good event to choose as the event that starts the
command timer, if any. The other events on your list could either be
thought of as 'zero time" or just not accounted for (e.g., part of the
service delivery delays that are not accounted for).
Note that entry into dormant state only accounts for Queue Command messages
received with simple or ordered attribute. You also have to account for
Queue Command message that are received with Head of Queue attribute and
ACA attribute (these go directly to Enabled state, so you need
modifications here to also set the timeout interval, if any).
On Fri, May 30, 2014 at 12:07 PM, Paul Suhler <Paul.Suhler at hgst.com> wrote:
>  It???s been suggested to me that the lack of a roar is because the lion
> sleeps Wednesday night through Sunday night.
>
>
>
> I???d like to check my understanding of 14-054r3 and how that affects my
> proposal:
>
>
>
> My intent is that a command may time out any time after arrival and before
> it first requests a data transfer.  In terms of T10/14-054r3, this
> corresponds to command states LU_CS2:Dormant and LU_CS3:Enabled.  The
> expiration time is computed when the command first arrives, as indicated by
> entry into LU_CS2:Dormant; this assumes that four events take place
> essentially at the same time, given adequate resources:
>
> a)		Arrival of the command at the SCSI Target Port.
>
> b)		Arrival at the TM of the SCSI Command Received message.
>
> c)		Arrival at the CS of the Queue Command message.
>
> d)		Entry into LU_CS2:Dormant.
>
>
>
> Is that assumption correct?
>
>
>
> I???d like not to introduce a new message.  Having specified in the model
> section the conditions upon which a timeout happens, can I just specify in
> the descriptions for LU_CS2 and LU_CS3 what happens when the timeout
> occurs?  This would be analogous to the description of the LU_DS state,
> which specifies what happens when an error occurs during command processing
>
>
>
> Or is a message to those states necessary?
>
>
>
> Thanks,
>
>
>
> Paul
>
>
>
> *From:* owner-t10 at t10.org [mailto:owner-t10 at t10.org] * On Behalf Of *Paul
> Suhler
> *Sent:* Thursday, May 29, 2014 9:31 AM
> *To:* T10 E-mail Reflector (t10 at t10.org)
> *Subject:* More: SAM-5 Command Timeout Subproposal for 14-107
>
>
>
> Okay, that attempt to provoke the lions??? den did not evoke any roars, so
> it must have been acceptable, *n???est pas*?	So, here???s another try:
>
>
>
> The previously-posted revision specified when a command timeout occurs.  I
> now propose to implement the timeout into the state machines by stating
> that when a timeout occurs, the device server sends a (newly-defined) *Time
> Out Command* message to the appropriate set of LU_CS states.	And I???ll
> define the resulting behaviors.
>
>
>
> Thanks,
>
>
>
> Paul
>
>
>
> *From:* owner-t10 at t10.org [mailto:owner-t10 at t10.org <owner-t10 at t10.org>]
*On
> Behalf Of *Paul Suhler
> *Sent:* Wednesday, May 28, 2014 4:01 PM
> *To:* T10 E-mail Reflector (t10 at t10.org)
> *Subject:* SAM-5 Command Timeout Subproposal for 14-107
>
>
>
> Hi, George (and anyone else who wishes to comment).
>
>
>
> As suggested in CAP in May, I???m trying to leverage the new state machines
> in 14-054 for defining the command deadline operations.  For example, in
> order to record the arrival time of a command and set its expiration time,
> I want to abandon adding an argument to the Route Command operation and
> instead hang it on a newly-defined transition.  Using 14-054r3 as a base, I
> propose to add the paragraph in blue:
>
>
>
> *8.9.4.2 LU_CS1:Idle state*
>
>
>
> *8.9.4.2.1 LU_CS1:Idle state description*
>
>
>
> This is the initial state of the LU_CS state machine.
>
>
>
> *8.9.4.2.2 Transition LU_CS1:Idle to LU_CS2:Dormant*
>
>
>
> This transition shall occur after receiving:
>
> a) a Queue Command message with a Task Attribute argument set to Simple; or
>
> b) a Queue Command message with a Task Attribute argument set to Ordered.
>
>
>
> This transition shall include the following arguments:
>
> a) I_T_L_Q Nexus;
>
> b) CDB;
>
> c) Task Attribute;
>
> d) CRN, if any;
>
> e) Command Priority, if any; and
>
> f) First Burst Enabled, if any.
>
>
>
> If this transition occurred after receiving a Queue Command message with a
> Task Attribute set to simple, then the Deadline Expiration time attribute
> of this command shall be set as specified in 8.7.2.2.
>
>
>
> The new subclause 8.7.2.2 relies upon the proposed command deadline clock,
> which is in the logical unit, and upon a command deadline value in the
> proposed Command Deadline mode page.
>
>
>
> Any problems with specifying this behavior here?  Other questions?
>
>
>
> Thanks,
>
>
>
> Paul
>
>
>
> *Paul A. Suhler, PhD*
>
> Research Staff Member
>
> HGST Research
> paul.suhler at hgst.com
> o: 949-476-1180 x275448
>
> m: 949-241-6443
>
> 3001 Daimler St.
> Santa Ana, CA 92705-5812
> www.hgst.com
>
>
>


From gerry.houlder at seagate.com  Fri May 30 10:51:44 2014
From: gerry.houlder at seagate.com (Gerry Houlder)
Date: Fri, 30 May 2014 12:51:44 -0500
Subject: Yet Another SAM-5 Command Timeout Subproposal for 14-107
Message-ID: <mailman.231.1441607401.22532.t10@sandbox.t10.org>

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

Another side effect that may have to be considered -- a command may be
received, to to dormant state, to to enabled state, go back to dormant, go
back to enabled several times before it gets processed. You would only want
the transition from Idle to either dormant or enabled to set the timeout --
entering enabled from dormant or dormant from enabled should not
recalculate the timeout.
On Fri, May 30, 2014 at 12:42 PM, Gerry Houlder <gerry.houlder at seagate.com>
wrote:
> It seems reasonable to me that the arrival at the CS of a Queue Command
> message (item c) is a good event to choose as the event that starts the
> command timer, if any. The other events on your list could either be
> thought of as 'zero time" or just not accounted for (e.g., part of the
> service delivery delays that are not accounted for).
>
> Note that entry into dormant state only accounts for Queue Command
> messages received with simple or ordered attribute. You also have to
> account for Queue Command message that are received with Head of Queue
> attribute and ACA attribute (these go directly to Enabled state, so you
> need modifications here to also set the timeout interval, if any).
>
>
> On Fri, May 30, 2014 at 12:07 PM, Paul Suhler <Paul.Suhler at hgst.com>
> wrote:
>
>>  It???s been suggested to me that the lack of a roar is because the lion
>> sleeps Wednesday night through Sunday night.
>>
>>
>>
>> I???d like to check my understanding of 14-054r3 and how that affects my
>> proposal:
>>
>>
>>
>> My intent is that a command may time out any time after arrival and
>> before it first requests a data transfer.  In terms of T10/14-054r3, this
>> corresponds to command states LU_CS2:Dormant and LU_CS3:Enabled.  The
>> expiration time is computed when the command first arrives, as indicated
by
>> entry into LU_CS2:Dormant; this assumes that four events take place
>> essentially at the same time, given adequate resources:
>>
>> a)		 Arrival of the command at the SCSI Target Port.
>>
>> b)		 Arrival at the TM of the SCSI Command Received message.
>>
>> c)		 Arrival at the CS of the Queue Command message.
>>
>> d)		 Entry into LU_CS2:Dormant.
>>
>>
>>
>> Is that assumption correct?
>>
>>
>>
>> I???d like not to introduce a new message.  Having specified in the model
>> section the conditions upon which a timeout happens, can I just specify in
>> the descriptions for LU_CS2 and LU_CS3 what happens when the timeout
>> occurs?  This would be analogous to the description of the LU_DS state,
>> which specifies what happens when an error occurs during command
processing
>>
>>
>>
>> Or is a message to those states necessary?
>>
>>
>>
>> Thanks,
>>
>>
>>
>> Paul
>>
>>
>>
>> *From:* owner-t10 at t10.org [mailto:owner-t10 at t10.org] * On Behalf Of *Paul
>> Suhler
>> *Sent:* Thursday, May 29, 2014 9:31 AM
>> *To:* T10 E-mail Reflector (t10 at t10.org)
>> *Subject:* More: SAM-5 Command Timeout Subproposal for 14-107
>>
>>
>>
>> Okay, that attempt to provoke the lions??? den did not evoke any roars, so
>> it must have been acceptable, *n???est pas*?  So, here???s another try:
>>
>>
>>
>> The previously-posted revision specified when a command timeout occurs.
>> I now propose to implement the timeout into the state machines by stating
>> that when a timeout occurs, the device server sends a (newly-defined)
*Time
>> Out Command* message to the appropriate set of LU_CS states.  And I???ll
>> define the resulting behaviors.
>>
>>
>>
>> Thanks,
>>
>>
>>
>> Paul
>>
>>
>>
>> *From:* owner-t10 at t10.org [mailto:owner-t10 at t10.org <owner-t10 at t10.org>]
*On
>> Behalf Of *Paul Suhler
>> *Sent:* Wednesday, May 28, 2014 4:01 PM
>> *To:* T10 E-mail Reflector (t10 at t10.org)
>> *Subject:* SAM-5 Command Timeout Subproposal for 14-107
>>
>>
>>
>> Hi, George (and anyone else who wishes to comment).
>>
>>
>>
>> As suggested in CAP in May, I???m trying to leverage the new state
machines
>> in 14-054 for defining the command deadline operations.  For example, in
>> order to record the arrival time of a command and set its expiration time,
>> I want to abandon adding an argument to the Route Command operation and
>> instead hang it on a newly-defined transition.  Using 14-054r3 as a base,
I
>> propose to add the paragraph in blue:
>>
>>
>>
>> *8.9.4.2 LU_CS1:Idle state*
>>
>>
>>
>> *8.9.4.2.1 LU_CS1:Idle state description*
>>
>>
>>
>> This is the initial state of the LU_CS state machine.
>>
>>
>>
>> *8.9.4.2.2 Transition LU_CS1:Idle to LU_CS2:Dormant*
>>
>>
>>
>> This transition shall occur after receiving:
>>
>> a) a Queue Command message with a Task Attribute argument set to Simple;
>> or
>>
>> b) a Queue Command message with a Task Attribute argument set to Ordered.
>>
>>
>>
>> This transition shall include the following arguments:
>>
>> a) I_T_L_Q Nexus;
>>
>> b) CDB;
>>
>> c) Task Attribute;
>>
>> d) CRN, if any;
>>
>> e) Command Priority, if any; and
>>
>> f) First Burst Enabled, if any.
>>
>>
>>
>> If this transition occurred after receiving a Queue Command message with
>> a Task Attribute set to simple, then the Deadline Expiration time
>> attribute of this command shall be set as specified in 8.7.2.2.
>>
>>
>>
>> The new subclause 8.7.2.2 relies upon the proposed command deadline
>> clock, which is in the logical unit, and upon a command deadline value in
>> the proposed Command Deadline mode page.
>>
>>
>>
>> Any problems with specifying this behavior here?  Other questions?
>>
>>
>>
>> Thanks,
>>
>>
>>
>> Paul
>>
>>
>>
>> *Paul A. Suhler, PhD*
>>
>> Research Staff Member
>>
>> HGST Research
>> paul.suhler at hgst.com
>> o: 949-476-1180 x275448
>>
>> m: 949-241-6443
>>
>> 3001 Daimler St.
>> Santa Ana, CA 92705-5812
>> www.hgst.com
>>
>>
>>
>
>


From Paul.Suhler at hgst.com  Fri May 30 10:58:13 2014
From: Paul.Suhler at hgst.com (Paul Suhler)
Date: Fri, 30 May 2014 17:58:13 +0000
Subject: Yet Another SAM-5 Command Timeout Subproposal for 14-107
Message-ID: <mailman.232.1441607401.22532.t10@sandbox.t10.org>

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

Thanks, Gerry.	I???d overlooked the possibility of re-entering Dormant.
As far as other states, the timeout proposal only applies to commands with
the SIMPLE attribute.
Paul
From: owner-t10 at t10.org [mailto:owner-t10 at t10.org] On Behalf Of Gerry Houlder
Sent: Friday, May 30, 2014 10:52 AM
To: T10 Reflector
Subject: Re: Yet Another SAM-5 Command Timeout Subproposal for 14-107
Another side effect that may have to be considered -- a command may be
received, to to dormant state, to to enabled state, go back to dormant, go
back to enabled several times before it gets processed. You would only want
the transition from Idle to either dormant or enabled to set the timeout --
entering enabled from dormant or dormant from enabled should not recalculate
the timeout.
On Fri, May 30, 2014 at 12:42 PM, Gerry Houlder
<gerry.houlder at seagate.com> wrote:
It seems reasonable to me that the arrival at the CS of a Queue Command
message (item c) is a good event to choose as the event that starts the
command timer, if any. The other events on your list could either be thought
of as 'zero time" or just not accounted for (e.g., part of the service
delivery delays that are not accounted for).
Note that entry into dormant state only accounts for Queue Command messages
received with simple or ordered attribute. You also have to account for Queue
Command message that are received with Head of Queue attribute and ACA
attribute (these go directly to Enabled state, so you need modifications here
to also set the timeout interval, if any).
On Fri, May 30, 2014 at 12:07 PM, Paul Suhler
<Paul.Suhler at hgst.com> wrote:
It???s been suggested to me that the lack of a roar is because the lion
sleeps Wednesday night through Sunday night.
I???d like to check my understanding of 14-054r3 and how that affects my
proposal:
My intent is that a command may time out any time after arrival and before it
first requests a data transfer.  In terms of T10/14-054r3, this corresponds
to command states LU_CS2:Dormant and LU_CS3:Enabled.  The expiration time is
computed when the command first arrives, as indicated by entry into
LU_CS2:Dormant; this assumes that four events take place essentially at the
same time, given adequate resources:
a)	      Arrival of the command at the SCSI Target Port.
b)	      Arrival at the TM of the SCSI Command Received message.
c)	      Arrival at the CS of the Queue Command message.
d)	      Entry into LU_CS2:Dormant.
Is that assumption correct?
I???d like not to introduce a new message.  Having specified in the model
section the conditions upon which a timeout happens, can I just specify in
the descriptions for LU_CS2 and LU_CS3 what happens when the timeout occurs? 
This would be analogous to the description of the LU_DS state, which
specifies what happens when an error occurs during command processing
Or is a message to those states necessary?
Thanks,
Paul
From: owner-t10 at t10.org<mailto:owner-t10 at t10.org>
[mailto:owner-t10 at t10.org<mailto:owner-t10 at t10.org>] On Behalf Of Paul Suhler
Sent: Thursday, May 29, 2014 9:31 AM
To: T10 E-mail Reflector (t10 at t10.org<mailto:t10 at t10.org>)
Subject: More: SAM-5 Command Timeout Subproposal for 14-107
Okay, that attempt to provoke the lions??? den did not evoke any roars, so it
must have been acceptable, n???est pas?  So, here???s another try:
The previously-posted revision specified when a command timeout occurs.  I
now propose to implement the timeout into the state machines by stating that
when a timeout occurs, the device server sends a (newly-defined) Time Out
Command message to the appropriate set of LU_CS states.  And I???ll define
the resulting behaviors.
Thanks,
Paul
From: owner-t10 at t10.org<mailto:owner-t10 at t10.org> [mailto:owner-t10 at t10.org]
On Behalf Of Paul Suhler
Sent: Wednesday, May 28, 2014 4:01 PM
To: T10 E-mail Reflector (t10 at t10.org<mailto:t10 at t10.org>)
Subject: SAM-5 Command Timeout Subproposal for 14-107
Hi, George (and anyone else who wishes to comment).
As suggested in CAP in May, I???m trying to leverage the new state machines
in 14-054 for defining the command deadline operations.  For example, in
order to record the arrival time of a command and set its expiration time, I
want to abandon adding an argument to the Route Command operation and instead
hang it on a newly-defined transition.	Using 14-054r3 as a base, I propose
to add the paragraph in blue:
8.9.4.2 LU_CS1:Idle state
8.9.4.2.1 LU_CS1:Idle state description
This is the initial state of the LU_CS state machine.
8.9.4.2.2 Transition LU_CS1:Idle to LU_CS2:Dormant
This transition shall occur after receiving:
a) a Queue Command message with a Task Attribute argument set to Simple; or
b) a Queue Command message with a Task Attribute argument set to Ordered.
This transition shall include the following arguments:
a) I_T_L_Q Nexus;
b) CDB;
c) Task Attribute;
d) CRN, if any;
e) Command Priority, if any; and
f) First Burst Enabled, if any.
If this transition occurred after receiving a Queue Command message with a
Task Attribute set to simple, then the Deadline Expiration time attribute of
this command shall be set as specified in 8.7.2.2.
The new subclause 8.7.2.2 relies upon the proposed command deadline clock,
which is in the logical unit, and upon a command deadline value in the
proposed Command Deadline mode page.
Any problems with specifying this behavior here?  Other questions?
Thanks,
Paul
Paul A. Suhler, PhD
Research Staff Member
HGST Research
paul.suhler at hgst.com
o: 949-476-1180 x275448
m: 949-241-6443
3001 Daimler St.
Santa Ana, CA 92705-5812
www.hgst.com<<a href="http://www.hgst.com/&gt">http://www.hgst.com/&gt;


From gerry.houlder at seagate.com  Fri May 30 11:29:47 2014
From: gerry.houlder at seagate.com (Gerry Houlder)
Date: Fri, 30 May 2014 13:29:47 -0500
Subject: Yet Another SAM-5 Command Timeout Subproposal for 14-107
Message-ID: <mailman.233.1441607401.22532.t10@sandbox.t10.org>

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

I wonder if restricting the command timeout feature to "SIMPLE attribute
only" is necessary. If we add that restriction, then we have to define what
happens when a command with non-zero GROUP field doesn't have a SIMPLE
attribute. Is it a frame error (the attribute is in the command frame
header), a CDB error, or do we ignore the GROUP field whenever the
attribute is not SIMPLE? We are already restricting the timeout feature to
only apply to read and write commands (which can be determined from the
CDB), so maybe we don't need to also restrict it based on the attribute.
On Fri, May 30, 2014 at 12:58 PM, Paul Suhler <Paul.Suhler at hgst.com> wrote:
>  Thanks, Gerry.  I???d overlooked the possibility of re-entering Dormant.
>
>
>
> As far as other states, the timeout proposal only applies to commands with
> the SIMPLE attribute.
>
>
>
> Paul
>
>
>
> *From:* owner-t10 at t10.org [mailto:owner-t10 at t10.org] *On Behalf Of *Gerry
> Houlder
> *Sent:* Friday, May 30, 2014 10:52 AM
> *To:* T10 Reflector
> *Subject:* Re: Yet Another SAM-5 Command Timeout Subproposal for 14-107
>
>
>
> Another side effect that may have to be considered -- a command may be
> received, to to dormant state, to to enabled state, go back to dormant, go
> back to enabled several times before it gets processed. You would only want
> the transition from Idle to either dormant or enabled to set the timeout --
> entering enabled from dormant or dormant from enabled should not
> recalculate the timeout.
>
>
>
> On Fri, May 30, 2014 at 12:42 PM, Gerry Houlder <gerry.houlder at seagate.com>
> wrote:
>
>  It seems reasonable to me that the arrival at the CS of a Queue Command
> message (item c) is a good event to choose as the event that starts the
> command timer, if any. The other events on your list could either be
> thought of as 'zero time" or just not accounted for (e.g., part of the
> service delivery delays that are not accounted for).
>
>
>
> Note that entry into dormant state only accounts for Queue Command
> messages received with simple or ordered attribute. You also have to
> account for Queue Command message that are received with Head of Queue
> attribute and ACA attribute (these go directly to Enabled state, so you
> need modifications here to also set the timeout interval, if any).
>
>
>
> On Fri, May 30, 2014 at 12:07 PM, Paul Suhler <Paul.Suhler at hgst.com>
> wrote:
>
>  It???s been suggested to me that the lack of a roar is because the lion
> sleeps Wednesday night through Sunday night.
>
>
>
> I???d like to check my understanding of 14-054r3 and how that affects my
> proposal:
>
>
>
> My intent is that a command may time out any time after arrival and before
> it first requests a data transfer.  In terms of T10/14-054r3, this
> corresponds to command states LU_CS2:Dormant and LU_CS3:Enabled.  The
> expiration time is computed when the command first arrives, as indicated by
> entry into LU_CS2:Dormant; this assumes that four events take place
> essentially at the same time, given adequate resources:
>
> a)		Arrival of the command at the SCSI Target Port.
>
> b)		Arrival at the TM of the SCSI Command Received message.
>
> c)		Arrival at the CS of the Queue Command message.
>
> d)		Entry into LU_CS2:Dormant.
>
>
>
> Is that assumption correct?
>
>
>
> I???d like not to introduce a new message.  Having specified in the model
> section the conditions upon which a timeout happens, can I just specify in
> the descriptions for LU_CS2 and LU_CS3 what happens when the timeout
> occurs?  This would be analogous to the description of the LU_DS state,
> which specifies what happens when an error occurs during command processing
>
>
>
> Or is a message to those states necessary?
>
>
>
> Thanks,
>
>
>
> Paul
>
>
>
> *From:* owner-t10 at t10.org [mailto:owner-t10 at t10.org] *On Behalf Of *Paul
> Suhler
> *Sent:* Thursday, May 29, 2014 9:31 AM
> *To:* T10 E-mail Reflector (t10 at t10.org)
> *Subject:* More: SAM-5 Command Timeout Subproposal for 14-107
>
>
>
> Okay, that attempt to provoke the lions??? den did not evoke any roars, so
> it must have been acceptable, *n???est pas*?	So, here???s another try:
>
>
>
> The previously-posted revision specified when a command timeout occurs.  I
> now propose to implement the timeout into the state machines by stating
> that when a timeout occurs, the device server sends a (newly-defined) *Time
> Out Command* message to the appropriate set of LU_CS states.	And I???ll
> define the resulting behaviors.
>
>
>
> Thanks,
>
>
>
> Paul
>
>
>
> *From:* owner-t10 at t10.org [mailto:owner-t10 at t10.org <owner-t10 at t10.org>]
*On
> Behalf Of *Paul Suhler
> *Sent:* Wednesday, May 28, 2014 4:01 PM
> *To:* T10 E-mail Reflector (t10 at t10.org)
> *Subject:* SAM-5 Command Timeout Subproposal for 14-107
>
>
>
> Hi, George (and anyone else who wishes to comment).
>
>
>
> As suggested in CAP in May, I???m trying to leverage the new state machines
> in 14-054 for defining the command deadline operations.  For example, in
> order to record the arrival time of a command and set its expiration time,
> I want to abandon adding an argument to the Route Command operation and
> instead hang it on a newly-defined transition.  Using 14-054r3 as a base, I
> propose to add the paragraph in blue:
>
>
>
> *8.9.4.2 LU_CS1:Idle state*
>
>
>
> *8.9.4.2.1 LU_CS1:Idle state description*
>
>
>
> This is the initial state of the LU_CS state machine.
>
>
>
> *8.9.4.2.2 Transition LU_CS1:Idle to LU_CS2:Dormant*
>
>
>
> This transition shall occur after receiving:
>
> a) a Queue Command message with a Task Attribute argument set to Simple; or
>
> b) a Queue Command message with a Task Attribute argument set to Ordered.
>
>
>
> This transition shall include the following arguments:
>
> a) I_T_L_Q Nexus;
>
> b) CDB;
>
> c) Task Attribute;
>
> d) CRN, if any;
>
> e) Command Priority, if any; and
>
> f) First Burst Enabled, if any.
>
>
>
> If this transition occurred after receiving a Queue Command message with a
> Task Attribute set to simple, then the Deadline Expiration time attribute
> of this command shall be set as specified in 8.7.2.2.
>
>
>
> The new subclause 8.7.2.2 relies upon the proposed command deadline clock,
> which is in the logical unit, and upon a command deadline value in the
> proposed Command Deadline mode page.
>
>
>
> Any problems with specifying this behavior here?  Other questions?
>
>
>
> Thanks,
>
>
>
> Paul
>
>
>
> *Paul A. Suhler, PhD*
>
> Research Staff Member
>
> HGST Research
> paul.suhler at hgst.com
> o: 949-476-1180 x275448
>
> m: 949-241-6443
>
> 3001 Daimler St.
> Santa Ana, CA 92705-5812
> www.hgst.com
>
>
>
>
>
>
>


From lohmeyer at t10.org  Sat May 31 23:01:51 2014
From: lohmeyer at t10.org (T10 Document Administrator)
Date: Sun, 1 Jun 2014 00:01:51 -0600
Subject: Recent T10 documents uploaded since 2014/05/25
Message-ID: <mailman.234.1441607401.22532.t10@sandbox.t10.org>

* From the T10 Reflector (t10 at t10.org), posted by:
* T10 Document Administrator <lohmeyer at t10.org>
*
Proposals
---------
SAM-5: State Machines Makeover
(by: George Penokie)
T10/14-054r3   Uploaded: 2014/05/28   392106 bytes
http://www.t10.org/cgi-bin/ac.pl?t=d&f=14-054r3.pdf
Minutes of T10 Plenary Meeting #121 - May 8, 2014
(by: Weber/Lohmeyer)
T10/14-119r1   Uploaded: 2014/05/27   123794 bytes
http://www.t10.org/cgi-bin/ac.pl?t=d&f=14-119r1.htm
Minutes of T10 Plenary Meeting #121 - May 8, 2014
(by: Weber/Lohmeyer)
T10/14-119r1   Uploaded: 2014/05/27   292504 bytes
http://www.t10.org/cgi-bin/ac.pl?t=d&f=14-119r1.pdf
Meeting Announcement: T10 Week Sep 8-12, 2014 -- Westborough, MA
(by: Mick Felton)
T10/14-142r1   Uploaded: 2014/05/27   94978 bytes
http://www.t10.org/cgi-bin/ac.pl?t=d&f=14-142r1.pdf
SPC-5: Storage initiated binding/unbinding (Implicit binding)
(by: Frederick Knight)
T10/14-146r0   Uploaded: 2014/05/28   161840 bytes
http://www.t10.org/cgi-bin/ac.pl?t=d&f=14-146r0.pdf
SPC-5:Redefinition of Peripheral Qualifier
(by: George Penokie)
T10/14-147r0   Uploaded: 2014/05/28   101781 bytes
http://www.t10.org/cgi-bin/ac.pl?t=d&f=14-147r0.pdf
Working Drafts
--------------
(Report generated on 2014/06/01 at 00:01:51)
*
* For T10 Reflector information, send a message with
* 'info t10' (no quotes) in the message body to majordomo at t10.org