From lohmeyer at t10.org  Sat Dec  1 23:00:40 2007
From: lohmeyer at t10.org (T10 Document Administrator)
Date: Sun, 2 Dec 2007 00:00:40 -0700
Subject: Recent T10 documents uploaded since 2007/11/25
Message-ID: <mailman.799.1441607323.22512.t10@sandbox.t10.org>

* From the T10 Reflector (t10 at t10.org), posted by:
* T10 Document Administrator <lohmeyer at t10.org>
*
Proposals
---------
Automation encryption control
(by: Curtis Ballard)
T10/07-164r8   Uploaded: 2007/11/26   177227 bytes
ftp://ftp.t10.org/t10/document.07/07-164r8.pdf
SSC-3: Out of Band Encryption Key Management
(by: Curtis Ballard)
T10/07-361r6   Uploaded: 2007/11/29   641536 bytes
ftp://ftp.t10.org/t10/document.07/07-361r6.doc
SSC-3: Out of Band Encryption Key Management
(by: Curtis Ballard)
T10/07-361r6   Uploaded: 2007/11/29   150430 bytes
ftp://ftp.t10.org/t10/document.07/07-361r6.pdf
Agenda: ADI Teleconference 28 November 2007
(by: Michael Banther)
T10/08-004r0   Uploaded: 2007/11/26   15421 bytes
ftp://ftp.t10.org/t10/document.08/08-004r0.pdf
SAS-2 Mode page tweaks
(by: Rob Elliott)
T10/08-005r0   Uploaded: 2007/11/28   29859 bytes
ftp://ftp.t10.org/t10/document.08/08-005r0.pdf
Minutes: SSC-3 29 Nov 2007 Phone Conference
(by: Kevin Butt)
T10/08-006r0   Uploaded: 2007/11/29   50232 bytes
ftp://ftp.t10.org/t10/document.08/08-006r0.pdf
Working Drafts
--------------
(Report generated on 2007/12/02 at 00:00:40)
*
* For T10 Reflector information, send a message with
* 'info t10' (no quotes) in the message body to majordomo at t10.org


From monika.talwar at nsysinc.com  Mon Dec  3 04:12:48 2007
From: monika.talwar at nsysinc.com (Mona)
Date: Mon, 03 Dec 2007 17:42:48 +0530
Subject: SAS Initiator XFER_RDY frame handling  
Message-ID: <mailman.800.1441607323.22512.t10@sandbox.t10.org>

Formatted message: <A HREF="r0712030_f.htm">HTML-formatted message</A>

Hi All,
Please refer to the last line of of Section 9.2.6.2.3.3.1 (sas2r13, 
Page#466)
    --------------------------------
    c) set the Previous Write Data Length state machine variable to the
    Requested Write Data Length
    Xfer_Rdy state machine argument.
    --------------------------------
I am not able to find the defination of Requested Write Data Length 
Xfer_Rdy state machine ardument. Is this the 'write data length' refered 
in bullet (e) of second last para in section 9.2.6.2.2.3(pasted below)
    -------------------------------- second last para in section
    9.2.6.2.2.3, Page#460
    If this state machine receives an ACK Transmitted confirmation for
    an XFER_RDY frame, then this state
    machine shall send an XFER_RDY Arrived message to ST_ITS state
    machine specified by the tag. The
    message shall include the following Xfer_Rdy arguments:
    a) retry data frames;
    b) retransmit bit;
    c) target port transfer tag;
    d) requested offset; and
    e) write data length
    -------------------------------- second last para in section 9.2.6.2.2.3
Please Suggest.
Thanks and best Regards
Mona


From curtis.stevens at wdc.com  Mon Dec  3 10:29:21 2007
From: curtis.stevens at wdc.com (Curtis Stevens)
Date: Mon, 3 Dec 2007 10:29:21 -0800
Subject: Room Block Reminder
Message-ID: <mailman.801.1441607323.22512.t10@sandbox.t10.org>

Formatted message: <A HREF="r0712031_f.htm">HTML-formatted message</A>

The rooms are disappearing fast for the January meeting.  The cut-off for
reservations is 14-Dec.  Please let me know if you are having trouble making
reservations.
-------------------------------------------------
Curtis E. Stevens
20511 Lake Forest Drive #C-214D
Lake Forest, California 92630
Phone: 949-672-7933
Cell: 949-307-5050
E-Mail: Curtis.Stevens at WDC.com  


From gop at us.ibm.com  Tue Dec  4 11:40:07 2007
From: gop at us.ibm.com (George Penokie)
Date: Tue, 4 Dec 2007 13:40:07 -0600
Subject: SAS Initiator XFER_RDY frame handling
Message-ID: <mailman.802.1441607323.22512.t10@sandbox.t10.org>

Formatted message: <A HREF="r0712040_f.htm">HTML-formatted message</A>

Mona,
The term was mislabeled as a result of an error in the 07-424 proposal. 
That proposal corrected the state machine argument by changing the name of 
the argument from  'Requested Offset Xfer_Rdy state machine argument' to 
the 'Requested Write Data Length Xfer_Rdy state machine argument'. The 
error was that the term 'requested' should also have been deleted. The 
correct name should have been 'Write Data Length Xfer_Rdy state machine 
argument'. 
Rob,
Do you consider that editorial or will it take a proposal to delete the 
offending word?
Bye for now,
George Penokie
Dept 9A8 030-3 A410
E-Mail:    gop at us.ibm.com
Internal:  553-5208
External: 507-253-5208
Mona <monika.talwar at nsysinc.com> 
Sent by: owner-t10 at t10.org
12/03/2007 06:12 AM
Please respond to
monika.talwar at nsysinc.com
To
t10 at t10.org
cc
Subject
SAS Initiator XFER_RDY frame handling
Hi All,
Please refer to the last line of of Section 9.2.6.2.3.3.1 (sas2r13, 
Page#466)
--------------------------------
c) set the Previous Write Data Length state machine variable to the 
Requested Write Data Length
Xfer_Rdy state machine argument.
--------------------------------
I am not able to find the defination of Requested Write Data Length 
Xfer_Rdy state machine ardument. Is this the 'write data length' refered 
in bullet (e) of second last para in section 9.2.6.2.2.3(pasted below) 
-------------------------------- second last para in section 9.2.6.2.2.3, 
Page#460
If this state machine receives an ACK Transmitted confirmation for an 
XFER_RDY frame, then this state
machine shall send an XFER_RDY Arrived message to ST_ITS state machine 
specified by the tag. The
message shall include the following Xfer_Rdy arguments:
a) retry data frames;
b) retransmit bit;
c) target port transfer tag;
d) requested offset; and
e) write data length
-------------------------------- second last para in section 9.2.6.2.2.3
Please Suggest.
Thanks and best Regards
Mona


From Elliott at hp.com  Tue Dec  4 12:15:56 2007
From: Elliott at hp.com (Elliott, Robert (Server Storage))
Date: Tue, 4 Dec 2007 20:15:56 +0000
Subject: SAS Initiator XFER_RDY frame handling
Message-ID: <mailman.803.1441607323.22512.t10@sandbox.t10.org>

Formatted message: <A HREF="r0712041_f.htm">HTML-formatted message</A>

Editorial; marked for sas2r14.
________________________________
From: George Penokie [mailto:gop at us.ibm.com]
Sent: Tuesday, December 04, 2007 1:40 PM
To: monika.talwar at nsysinc.com; Elliott, Robert (Server Storage)
Cc: owner-t10 at t10.org; t10 at t10.org
Subject: Re: SAS Initiator XFER_RDY frame handling
Mona,
The term was mislabeled as a result of an error in the 07-424 proposal. That
proposal corrected the state machine argument by changing the name of the
argument from  'Requested Offset Xfer_Rdy state machine argument' to the
'Requested Write Data Length Xfer_Rdy state machine argument'. The error was
that the term 'requested' should also have been deleted. The correct name
should have been 'Write Data Length Xfer_Rdy state machine argument'.
Rob,
Do you consider that editorial or will it take a proposal to delete the
offending word?
Bye for now,
George Penokie
Dept 9A8 030-3 A410
E-Mail:    gop at us.ibm.com
Internal:  553-5208
External: 507-253-5208
Mona <monika.talwar at nsysinc.com>
Sent by: owner-t10 at t10.org
12/03/2007 06:12 AM
Please respond to
monika.talwar at nsysinc.com
To
t10 at t10.org
cc
Subject
SAS Initiator XFER_RDY frame handling
Hi All,
Please refer to the last line of of Section 9.2.6.2.3.3.1 (sas2r13, Page#466)
--------------------------------
c) set the Previous Write Data Length state machine variable to the Requested
Write Data Length
Xfer_Rdy state machine argument.
--------------------------------
I am not able to find the defination of Requested Write Data Length Xfer_Rdy
state machine ardument. Is this the 'write data length' refered in bullet (e)
of second last para in section 9.2.6.2.2.3(pasted below)
-------------------------------- second last para in section 9.2.6.2.2.3,
Page#460
If this state machine receives an ACK Transmitted confirmation for an
XFER_RDY frame, then this state
machine shall send an XFER_RDY Arrived message to ST_ITS state machine
specified by the tag. The
message shall include the following Xfer_Rdy arguments:
a) retry data frames;
b) retransmit bit;
c) target port transfer tag;
d) requested offset; and
e) write data length
-------------------------------- second last para in section 9.2.6.2.2.3
Please Suggest.
Thanks and best Regards
Mona


From keiji_katata at post.pioneer.co.jp  Tue Dec  4 17:41:13 2007
From: keiji_katata at post.pioneer.co.jp (keiji_katata at post.pioneer.co.jp)
Date: Wed, 5 Dec 2007 10:41:13 +0900
Subject: Posted: Microsoft-Toshiba proposal
Message-ID: <mailman.804.1441607323.22512.t10@sandbox.t10.org>

* From the T10 Reflector (t10 at t10.org), posted by:
* keiji_katata at post.pioneer.co.jp
*
Hello all,
I posted the proposal document on ftp.
ftp.avc-pioneer.com/Mtfuji_7/Proposal/Dec07/Microsoft/Mt Fuji proposal -
Speed
control - 23.zip
Best regards,
Keiji Katata
PIONEER CORP.
*
* For T10 Reflector information, send a message with
* 'info t10' (no quotes) in the message body to majordomo at t10.org


From keiji_katata at post.pioneer.co.jp  Tue Dec  4 18:07:27 2007
From: keiji_katata at post.pioneer.co.jp (keiji_katata at post.pioneer.co.jp)
Date: Wed, 5 Dec 2007 11:07:27 +0900
Subject: Reflector cleanup notice
Message-ID: <mailman.805.1441607323.22512.t10@sandbox.t10.org>

* From the T10 Reflector (t10 at t10.org), posted by:
* keiji_katata at post.pioneer.co.jp
*
Hello all,
The following people have bounced repeatedly and removed from mtfuji5
reflector:
dracula at lge.com
emhill at windows.microsoft.com
They may get back on the reflector by sending a message to
majordomo at avc-pioneer.com with the following line in the message body:
subscribe mtfuji5
Best regards,
Keiji Katata
PIONEER CORP.
*
* For T10 Reflector information, send a message with
* 'info t10' (no quotes) in the message body to majordomo at t10.org


From michael.banther at hp.com  Fri Dec  7 06:01:40 2007
From: michael.banther at hp.com (Banther, Michael)
Date: Fri, 7 Dec 2007 14:01:40 +0000
Subject: ADI-2 ad-hoc teleconference
Message-ID: <mailman.806.1441607323.22512.t10@sandbox.t10.org>

Formatted message: <A HREF="r0712070_f.htm">HTML-formatted message</A>
Attachment #1: <A HREF="r0712070_banther_michael-3.vcf">banther_michael-3.vcf</A>

The ADI-2 working group will hold an ad-hoc teleconference on 12 December
2007 starting at 8:00 AM PST and concluding at 10:00 AM PST.  You can find
the agenda, including contact details, at
http://www.t10.org/ftp/t10/document.08/08-012r0.pdf.
Regards,
Michael Banther
Tel. +44 117 312 9503
Hewlett-Packard Limited registered Office:
Cain Road, Bracknell, Berks RG12 1HN
Registered No: 690597 England
The contents of this message and any attachments to it are confidential and
may be legally privileged. If you have received this message in error, you
should delete it from your system immediately and advise the sender.
To any recipient of this message within HP, unless otherwise stated you
should consider this message and attachments as "HP CONFIDENTIAL".


From lohmeyer at t10.org  Sat Dec  8 23:00:56 2007
From: lohmeyer at t10.org (T10 Document Administrator)
Date: Sun, 9 Dec 2007 00:00:56 -0700
Subject: Recent T10 documents uploaded since 2007/12/02
Message-ID: <mailman.807.1441607323.22512.t10@sandbox.t10.org>

* From the T10 Reflector (t10 at t10.org), posted by:
* T10 Document Administrator <lohmeyer at t10.org>
*
Proposals
---------
Capability based Command Security
(by: George O. Penokie)
T10/07-454r3   Uploaded: 2007/12/06   398672 bytes
ftp://ftp.t10.org/t10/document.07/07-454r3.pdf
SAM-4 SPC-4 SBC-3 Unit attention condition queuing
(by: Rob Elliott)
T10/07-459r2   Uploaded: 2007/12/04   185349 bytes
ftp://ftp.t10.org/t10/document.07/07-459r2.pdf
Minutes: ADI Teleconference 28 November 2007
(by: Michael Banther)
T10/08-003r0   Uploaded: 2007/12/07   19138 bytes
ftp://ftp.t10.org/t10/document.08/08-003r0.pdf
SAS-2: Transport layer read and write flowcharts
(by: George O. Penokie)
T10/08-007r0   Uploaded: 2007/12/03   102465 bytes
ftp://ftp.t10.org/t10/document.08/08-007r0.pdf
SPC-4 Download microcode I_T nexus usage
(by: Rob Elliott)
T10/08-008r0   Uploaded: 2007/12/05   31860 bytes
ftp://ftp.t10.org/t10/document.08/08-008r0.pdf
SAS-2 Elasticity buffer clarifications
(by: Rob Elliott)
T10/08-009r0   Uploaded: 2007/12/06   147789 bytes
ftp://ftp.t10.org/t10/document.08/08-009r0.pdf
SAS-2 XL Forward Dword correction
(by: Rob Elliott)
T10/08-011r0   Uploaded: 2007/12/06   260123 bytes
ftp://ftp.t10.org/t10/document.08/08-011r0.pdf
Agenda: ADI Teleconference 12 December 2007
(by: Michael Banther)
T10/08-012r0   Uploaded: 2007/12/07   15305 bytes
ftp://ftp.t10.org/t10/document.08/08-012r0.pdf
SAT-2 Add translation for Block Charactaristics VPD Page
(by: Brad Besmer)
T10/08-016r0   Uploaded: 2007/12/07   75818 bytes
ftp://ftp.t10.org/t10/document.08/08-016r0.pdf
Working Drafts
--------------
(Report generated on 2007/12/09 at 00:00:56)
*
* For T10 Reflector information, send a message with
* 'info t10' (no quotes) in the message body to majordomo at t10.org


From shunsuke.kimura at toshiba.co.jp  Sun Dec  9 20:45:40 2007
From: shunsuke.kimura at toshiba.co.jp (Shunsuke Kimura)
Date: Mon, 10 Dec 2007 13:45:40 +0900
Subject: December Mt.Fuji meeting announcement
Message-ID: <mailman.808.1441607323.22512.t10@sandbox.t10.org>

* From the T10 Reflector (t10 at t10.org), posted by:
* Shunsuke Kimura <shunsuke.kimura at toshiba.co.jp>
*
Dear All,
I'm sorry for this late announcement.
The December Mt.Fuji meeting will be held as follows;
-----------------------------------------------------------------------------
------
1. Date & Time
	December 18th and 19th (Tuesday and Wednesday)	 10:00 am - 5:00 pm
2. Place
	Toshiba Headquarters Building
	http://www.toshiba.co.jp/worldwide/about/overseas.html
	Meeting Room:	Room #3919 (39th floor)
3. Request for attendees
	Please inform me the attendants by "December 17 (Japan Time)".
	NOTE: ATTENDEE LIST is required for security reason and preparing
	the meeting facilities.
-----------------------------------------------------------------------------
------
Best Regards,
Shunsuke Kimura
Toshiba
*
* For T10 Reflector information, send a message with
* 'info t10' (no quotes) in the message body to majordomo at t10.org


From gop at us.ibm.com  Mon Dec 10 12:41:24 2007
From: gop at us.ibm.com (George Penokie)
Date: Mon, 10 Dec 2007 14:41:24 -0600
Subject: SAM-4 letter ballot resolution calls
Message-ID: <mailman.809.1441607323.22512.t10@sandbox.t10.org>

Formatted message: <A HREF="r0712100_f.htm">HTML-formatted message</A>

There will be four SAM-4 letter ballot resolution meetings between now and 
the end of the year on the dates listed below. John Lohmeyer of LSI is 
able to provide a webex connection of the first meeting on 12/14. Call-in 
if you are interested in this topic.
12/14/2007 - 10:00 am - noon (central time)
12/17/2007 - 10:00 am - noon (central time)
12/19/2007 - 03:00 pm - 05:00 pm (central time)
12/21/2007 - 10:00 am - noon (central time)
The webex information of the call on 12/14/2007 is as follows:
Topic: SAM-4 Letter Ballot 
Date: Friday, December 14, 2007 
Time: 10:00 am, Central Standard Time (GMT -06:00, Chicago ) 
Meeting Number: 570 547 640 
Meeting Password: Resolve 
Please click the link below to see more information, or to join the 
meeting. 
------------------------------------------------------- 
To join the online meeting 
------------------------------------------------------- 
1. Go to https://lsilogic.webex.com/lsilogic/j.php?ED=102386652&UID=0 
2. Enter your name and email address. 
3. Enter the meeting password: Resolve 
4. Click "Join". 
Bye for now,
George Penokie
Dept 9A8 030-3 A410
E-Mail:    gop at us.ibm.com
Internal:  553-5208


From gop at us.ibm.com  Mon Dec 10 12:43:46 2007
From: gop at us.ibm.com (George Penokie)
Date: Mon, 10 Dec 2007 14:43:46 -0600
Subject: SAM-4 letter ballot resolution calls (with call-in number)
Message-ID: <mailman.810.1441607323.22512.t10@sandbox.t10.org>

Formatted message: <A HREF="r0712101_f.htm">HTML-formatted message</A>

George Penokie/Rochester/IBM 
12/10/2007 02:41 PM
To
T10 Reflector
cc
bob.nixon at emulex.com, "Elliott, Robert \(Server Storage\)" 
<Elliott at hp.com>, lohmeyer at t10.org, paul.suhler at quantum.com, 
roweber at ieee.org, mark.evans at wdc.com
Subject
SAM-4 letter ballot resolution calls
There will be four SAM-4 letter ballot resolution meetings between now and 
the end of the year on the dates listed below. John Lohmeyer of LSI is 
able to provide a webex connection of the first meeting on 12/14. Call-in 
if you are interested in this topic.
12/14/2007 - 10:00 am - noon (central time)
12/17/2007 - 10:00 am - noon (central time)
12/19/2007 - 03:00 pm - 05:00 pm (central time)
12/21/2007 - 10:00 am - noon (central time)
Audio Conference Access Numbers
USA: 770-615-1254 (Note: this number may be a problem in some locations), 
Tie-Line 421-0038 or 1-877-421-0038
Passcode: 198458 
The webex information of the call on 12/14/2007 is as follows:
Topic: SAM-4 Letter Ballot 
Date: Friday, December 14, 2007 
Time: 10:00 am, Central Standard Time (GMT -06:00, Chicago ) 
Meeting Number: 570 547 640 
Meeting Password: Resolve 
Please click the link below to see more information, or to join the 
meeting. 
------------------------------------------------------- 
To join the online meeting 
------------------------------------------------------- 
1. Go to https://lsilogic.webex.com/lsilogic/j.php?ED=102386652&UID=0 
2. Enter your name and email address. 
3. Enter the meeting password: Resolve 
4. Click "Join". 
Bye for now,
George Penokie
Dept 9A8 030-3 A410
E-Mail:    gop at us.ibm.com
Internal:  553-5208
External: 507-253-5208


From kdbutt at us.ibm.com  Mon Dec 10 13:17:50 2007
From: kdbutt at us.ibm.com (Kevin D Butt)
Date: Mon, 10 Dec 2007 14:17:50 -0700
Subject: Persistent Reservation Proposal - Group Reservations
Message-ID: <mailman.811.1441607323.22512.t10@sandbox.t10.org>

Formatted message: <A HREF="r0712102_f.htm">HTML-formatted message</A>

I have posted two documents related to an additional Persistent 
Reservation Type.  The first document is a presentation on where 
persistent reservations are today and where they fall short in the 
scenarios covered by the proposal.  It also covers the intent of the 
proposal and what will be proposed.  The second is the actual proposal
Your PDF file will be posted at:
   http://www.t10.org/ftp/t10/document.08/08-024r0.pdf
   http://www.t10.org/ftp/t10/document.08/08-025r0.pdf
Normally, the posting/archiving process takes about 30 minutes.
Kevin D. Butt
SCSI & Fibre Channel Architect, Tape Firmware, IBM
MS 6TYA, 9000 S. Rita Rd., Tucson, AZ 85744
Tel: 520-799-2869 / 520-799-5280
Fax: 520-799-2723 (T/L:321)
Email address: kdbutt at us.ibm.com


From Paul.Suhler at Quantum.Com  Mon Dec 10 15:41:25 2007
From: Paul.Suhler at Quantum.Com (Paul Suhler)
Date: Mon, 10 Dec 2007 15:41:25 -0800
Subject: ADI Working Group Teleconference 12 December 2007
Message-ID: <mailman.812.1441607323.22512.t10@sandbox.t10.org>

Attachment #1: <A HREF="r0712103_smime-3.p7s">smime-3.p7s</A>

There will be an ADI working group teleconference Wednesday, 12 December, 
8:00 - 10:00 AM PST.  The contact information below has changed from that in 
T10/08-012r0.  Please check the T10 web site for an update to 07-164r8.
Thanks,
Paul Suhler
Quantum Corporation
Date -- 12 December 2007
Time 8:00 AM -- 10:00 AM PST
Meeting ID:	  3029
Meeting Password: none
Phone Number(s):  719-536-6600
US Toll Free:	  800-668-7083
International Toll Free: Europe and PAC Rim International Code +
800-6006-0066 
(Argentina, Belgium, Brazil, Denmark, Finland, France, Germany, Hungary, 
Ireland, Israel, Italy, Japan, Korea, Luxembourg, Netherlands, Norway,
Penang, 
Poland, Portugal, South Africa, Spain, Switzerland, Sweden, United Kingdom)
TO ATTEND THE WEB CONFERENCE AND THEN JOIN WITH AUDIO:
1. Go to:  http://mponline.quantum.com/a/2338e3f669af28f19a3c4160f4b8238b
2. Sign in as a Guest or with your Cisco MeetingPlace User ID, and click on 
Attend Meeting.
   - Accept any security warnings you receive and wait for the Meeting Room
to 
initialize.
3. Click on CONNECT and enter your phone and click OK. The system will now 
call you.
TEST YOUR BROWSER BEFORE YOU ATTEND YOUR FIRST WEB CONFERENCE
Visit http://mponline.quantum.com/test/ to test your web browser for 
compatibility with the web conference.
AGENDA:
1. Introductions [Group]
2. Approval of the agenda [Suhler]
3. Attendance and Membership [Suhler]
4. INCITS Patent Policy (see T10 Short Summary at 
http://www.t10.org/patpol.htm) [Suhler]
5. Approval of previous meeting minutes [Suhler]
6. Call for Secretary
7. Review of action items [Banther]
8. Old Business
8.1 Automation encryption control (07-164r8) [Ballard]
8.2 ADT-2: SCSI Command IU to Initiator only port (07-438r0) [Entzel]
9. New Business
10. Next Meeting Requirements [Suhler]
11. Review New Action Items [Banther]
12. Adjournment [Suhler]
-----------------------------------------------------------
The information contained in this transmission may be 
confidential. Any disclosure, copying, or further 
distribution of confidential information is not permitted 
unless such privilege is explicitly granted in writing by 
Quantum Corporation. Furthermore, Quantum Corporation is not 
responsible for the proper and complete transmission of the 
substance of this communication or for any delay in its 
receipt.


From lohmeyer at t10.org  Mon Dec 10 20:54:56 2007
From: lohmeyer at t10.org (John Lohmeyer)
Date: Mon, 10 Dec 2007 21:54:56 -0700
Subject: SAT-2 Working Group minutes posted
Message-ID: <mailman.813.1441607323.22512.t10@sandbox.t10.org>

* From the T10 Reflector (t10 at t10.org), posted by:
* John Lohmeyer <lohmeyer at t10.org>
*
The draft SAT-2 working group minutes of the December 10, 2007 meeting are
available at:
   http://www.t10.org/ftp/t10/document.08/08-017r0.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 curtis.ballard at hp.com  Tue Dec 11 13:37:07 2007
From: curtis.ballard at hp.com (Ballard, Curtis C (StorageWorks))
Date: Tue, 11 Dec 2007 21:37:07 +0000
Subject: Final revision of T10/07-164r9 posted
Message-ID: <mailman.814.1441607323.22512.t10@sandbox.t10.org>

* From the T10 Reflector (t10 at t10.org), posted by:
* "Ballard, Curtis C (StorageWorks)" <curtis.ballard at hp.com>
*
I have posted 07-164r9 at the following link
Curtis
-----Original Message-----
From: Administrator at scsibbs.co.lsil.com
[mailto:Administrator at scsibbs.co.lsil.com] On Behalf Of T10 Document
Administrator
Sent: Tuesday, December 11, 2007 2:29 PM
To: Ballard, Curtis C (StorageWorks)
Subject: Re: Re: T10 Document Number Assigned (T10/07-164r9)
2007/12/11 14:29:13
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/ftp/t10/document.07/07-164r9.pdf
Normally, the posting/archiving process takes about 30 minutes.
Please contact John Lohmeyer <lohmeyer at t10.org>
should you need further assistance.
curtis.ballard at hp.com wrote:
> Date: Tue Dec 11 14:28:46 2007
> From: curtis.ballard at hp.com
> To: T10 Document Administrator via web upload <docs at t10.org>
> Subject: Re: T10 Document Number Assigned (T10/07-164r9)
>
> T10 document upload details:
>
>   Document Number: T10/07-164r9
>	Upload Code: AC_03663rgnsy2ikVB
>     Document_Date: 2007/12/11
>   Document_Author: Curtis Ballard
>    Document_Title: Automation encryption control
>    Meeting_Agenda: none
> Document_Comments: <none>
>      Other_Number: <none>
>	  Post_File: pdf
>
> ## COPYRIGHT POLICY
> ## ----------------
> ##
> ## Do not submit documents containing a copyright statement
> ## unless you add the following statement:
> ##
> ##	Permission is granted to members of INCITS, its technical
> ##	committees and their associated task groups to reproduce
> ##	this document for the purposes of INCITS standardization
> ##	activities, provided this notice is included.
> ##
> ## If you upload a copyrighted document, with or without
> ## this statement, it will be assumed implicitly that you
> ## and your organization have given the above permission.
> ##
> ##
> ## APPROPRIATE CONTENT
> ## -------------------
> ##
> ## Do not upload inappropriate material.  If you do, your
> ## files will be removed and your posting privileges will
> ## be revoked.
>
> Attachment Converted: "D:\T10\ATTACH\07-164r9.pdf"
>
*
* For T10 Reflector information, send a message with
* 'info t10' (no quotes) in the message body to majordomo at t10.org


From Bill.Martin at emulex.com  Tue Dec 11 20:18:25 2007
From: Bill.Martin at emulex.com (Bill.Martin at emulex.com)
Date: Tue, 11 Dec 2007 20:18:25 -0800
Subject: Zoning value issue
Message-ID: <mailman.815.1441607323.22512.t10@sandbox.t10.org>

Formatted message: <A HREF="r0712111_f.htm">HTML-formatted message</A>

There is a discrepancy in SAS 2 related to the zoning values.  There are
definitions for default values, saved values, and shadow values in the
DISCOVER Response; however, the definitions are all the same - they all
reference the default value. 
Bill Martin
Emulex
Office of Technology
Industry Standards
916 772-3658
916 765-6875 (Cell)
bill.martin at emulex.com


From plavarre at lexar.com  Wed Dec 12 09:49:49 2007
From: plavarre at lexar.com (plavarre at lexar.com)
Date: Wed, 12 Dec 2007 09:49:49 -0800
Subject: SPC Inquiry for Quad-Aligned Zero -- deprecated since SPC-4 maybe
Message-ID: <mailman.816.1441607323.22512.t10@sandbox.t10.org>

* From the T10 Reflector (t10 at t10.org), posted by:
* <plavarre at lexar.com>
*
> http://t10.org/scsi-3.htm
> http://t10.org/ftp/t10/drafts/spc4/spc4r11.pdf
> 14 May 2007
> ...
> 6.4 INQUIRY command
> 6.4.1 INQUIRY command introduction
> ...
>
> The ALLOCATION LENGTH field is defined in 4.3.4.6.
>
> If EVPD is set to zero,
> the allocation length should be at least five,
> so that the ADDITIONAL LENGTH field
> in the parameter data (see 6.4.2) is returned.
>
> If EVPD is set to one,
> the allocation length should be should be at least four,
> so that the PAGE LENGTH field
> in the parameter data (see 7.6) is returned.
Whoa.
Do we actually now mean to be so explicitly deprecating the SCSI test
tradition of SPC Inquiry for zero?
"12 00 00 00 00 00" is the six byte hex CDB I mean.
The tradition I knew was: "The host may send this CDB to discover if
Command Out and Status In works without simultaneously testing Data Out,
Data In, and Sense In and without risk of popping a Unit Attention
(though with the risk of wiping out some read-and-clear Sense data)."
So in future SPC do we mean "any nonzero allocation length should be at
least four" or do we mean "every allocation length should be at least
four" or do we mean something else?
Curiously yours, thanks in advance,
P.S. And while we're here does anyone happen to know where our language
is that recommends SPC Inquiry Allocation Lengths be quad-aligned for
SCSI transports that require quad-aligned data phases?
*
* For T10 Reflector information, send a message with
* 'info t10' (no quotes) in the message body to majordomo at t10.org


From mikeb at bustrace.com  Wed Dec 12 10:49:06 2007
From: mikeb at bustrace.com (Mike Berhan)
Date: Wed, 12 Dec 2007 10:49:06 -0800
Subject: SAS - Protocol-Specific Port log page
Message-ID: <mailman.817.1441607323.22512.t10@sandbox.t10.org>

Formatted message: <A HREF="r0712121_f.htm">HTML-formatted message</A>
Attachment #1: <A HREF="r0712121_image001.png">image001.png</A>
Attachment #2: <A HREF="r0712121_image002.png">image002.png</A>

I am currently working with a SAS 1.1 device and reviewing the SAS-1.1 and
SAS-2 specification.  I have some questions / comments regarding the
protocol specific port log page for SAS.  Before I get to that, I need to
provide some simple screenshots of an actual SAS 1.1 device to help describe
my question.
The first eight bytes of the "Protocol-Specific Port log parameter for SAS"
are similar between SAS-1.1 and SAS-2.	The SAS-1.1 decoding is below.
SAS-2 marks the "DS" bit as Obsolete, uses "Format and Linking" instead of
"LBIN" and "LP", and defines offset 6 as the "Generation Code."
An array of "SAS Phy Log Desriptor" entries follows this 8 byte header.  The
number of entries in the array is given to us in the "Number of Phys" entry
seen above.  OK, so far so good.
In reviewing SAS-1.1, the SAS phy log descriptor is a fixed 48 byte
structure as you see here:
Traversing through the array of SAS phy log descriptors is rather simple as
you know the number of Phys and you know that each descriptor is 48 bytes in
length.
The complexity comes with SAS-2.  This specification defines variable length
SAS phy log descriptors.  Offset 3 of the above structure is now defined as
the "SAS Phy Log Descriptor Length".  The structure is	larger than 48 bytes
and contains a variable number of Phy Event Descriptors.
In my task, I do not have the luxury of enumerating various information from
the device so I do not know if it's a SAS-1.1 or SAS-2 device.	All I have
is the log sense data to analyze.  I need to know if I'm looking at a
SAS-1.1 descriptor or a SAS-2 descriptor.  The first method, or perhaps I
should call it a hack, that comes to mind is:
If ( DescriptorOffset[3]==0 )
   // It's a fixed 48 byte descriptor (i.e. SAS-1.1)
else
   // it's a variable length descriptor, total len = DescriptorOffset[3]+4
Now finally to my question.  If all I have access to is this log page, would
the above pseudo code be the preferred method of knowing which descriptor
the device is returning?  If not, is there another field in the descriptor
that would be preferred?  Should a "Version" field be introduced so that the
application layer knows which version of the structure they are looking at
and which fields are valid?
Another question.  If I could enumerate more information from the device,
what would be the preferred way to detect a SAS-1.1 vs SAS-2 device from the
application layer?  Would the "Version Descriptors" in the Inquiry page be
the recommended method?
Thinking out loud, should SAS-2 introduce a new "cleaner" sub-page instead
of expanding the current page?	I am not a big fan of variable sized arrays
nested within other variable sized arrays.
-------
Mike Berhan
busTRACE Technologies
9700 Village Center Drive
Suite 50-F
Granite Bay, CA  95746
916.773.4554 phone
916.218.6283 fax
http://www.bustrace.com


From Elliott at hp.com  Wed Dec 12 11:52:15 2007
From: Elliott at hp.com (Elliott, Robert (Server Storage))
Date: Wed, 12 Dec 2007 19:52:15 +0000
Subject: SPC Inquiry for Quad-Aligned Zero -- deprecated since SPC-4
 maybe
Message-ID: <mailman.818.1441607323.22512.t10@sandbox.t10.org>

* From the T10 Reflector (t10 at t10.org), posted by:
* "Elliott, Robert (Server Storage)" <Elliott at hp.com>
*
> -----Original Message-----
> From: owner-t10 at t10.org [mailto:owner-t10 at t10.org] On Behalf
> Of plavarre at lexar.com
> Sent: Wednesday, December 12, 2007 11:50 AM
> To: T10 at t10.org
> Subject: SPC Inquiry for Quad-Aligned Zero -- deprecated
> since SPC-4 maybe
>
> * From the T10 Reflector (t10 at t10.org), posted by:
> * <plavarre at lexar.com>
> *
> > http://t10.org/scsi-3.htm
> > http://t10.org/ftp/t10/drafts/spc4/spc4r11.pdf
> > 14 May 2007
> > ...
> > 6.4 INQUIRY command
> > 6.4.1 INQUIRY command introduction
> > ...
> >
> > The ALLOCATION LENGTH field is defined in 4.3.4.6.
> >
> > If EVPD is set to zero,
> > the allocation length should be at least five,
> > so that the ADDITIONAL LENGTH field
> > in the parameter data (see 6.4.2) is returned.
> >
> > If EVPD is set to one,
> > the allocation length should be should be at least four,
> > so that the PAGE LENGTH field
> > in the parameter data (see 7.6) is returned.
>
> Whoa.
>
> Do we actually now mean to be so explicitly deprecating the SCSI test
> tradition of SPC Inquiry for zero?
>
> "12 00 00 00 00 00" is the six byte hex CDB I mean.
>
> The tradition I knew was: "The host may send this CDB to discover if
> Command Out and Status In works without simultaneously
> testing Data Out,
> Data In, and Sense In and without risk of popping a Unit Attention
> (though with the risk of wiping out some read-and-clear Sense data)."
>
> So in future SPC do we mean "any nonzero allocation length
> should be at
> least four" or do we mean "every allocation length should be at least
> four" or do we mean something else?
Those are just "should" not "shall" rules, so zero doesn't violate them.  The
sentences explain why the advice is provided - a value less than 4 or 5
results in a truncated LENGTH field, which could be misinterpreted.
The general ALLOCATION LENGTH field definition in 4.3.4.6 (used by most but
not all commands that have a field with that name) specifically says zero is
not an error.  INQUIRY uses the 4.3.4.6 definition.
One editorial clarification: "should be should be" should be "should be"
> Curiously yours, thanks in advance,
>
> P.S. And while we're here does anyone happen to know where
> our language
> is that recommends SPC Inquiry Allocation Lengths be quad-aligned for
> SCSI transports that require quad-aligned data phases?
The SCSI Architecture Model requires SCSI transports to support
byte precision for transfer lengths.
The wording in SAM-4 revision 13b section 5.4.3.1 is:
"All SCSI transport protocol standards shall define support for
 a resolution of one byte for the Application Client Buffer
 Size argument."
It allows transports to ensure that interim transfers are aligned
on larger boundaries, as long as the last transfer can deliver
any specific number of bytes:
"SCSI transport protocol standards may define restrictions on
 the resolution of the Application Client Buffer Offset argument.
 SCSI transport protocol standards may define restrictions on the
 resolution of the Request Byte Count argument for any call to
 Send Data-In or any call to Receive Data-Out that does not
 transfer the last byte of the Application Client Buffer."
--
Rob Elliott, elliott at hp.com
Hewlett-Packard Industry Standard Server Storage Advanced Technology
*
* For T10 Reflector information, send a message with
* 'info t10' (no quotes) in the message body to majordomo at t10.org


From Alvin.Cox at seagate.com  Wed Dec 12 12:14:01 2007
From: Alvin.Cox at seagate.com (Alvin.Cox at seagate.com)
Date: Wed, 12 Dec 2007 14:14:01 -0600
Subject: Reminder, SAS PHY WG call, Dec 13, 10:00am CST
Message-ID: <mailman.819.1441607323.22512.t10@sandbox.t10.org>

Formatted message: <A HREF="r0712123_f.htm">HTML-formatted message</A>

The agenda below is based on the previous status of the PHY specification. 
Due to my extended leave and current ISP and telephone service issues 
resulting from the ice storms in Oklahoma, I have not been able to review 
emails prior to making this agenda. The call will be conducted and the 
agenda may be modified based on particiapant input.
Conference calls on Thursday at 10:00 am Central time.
Next conference call: 12/13/07 
Toll Free Dial in Number: (877)810-9442 
International Access/Caller Paid Dial In Number: (636)651-3190 
PARTICIPANT CODE: 3243413 
Webex information: 
https://seagate.webex.com/seagate 
Topic: SAS-2 PHY WG 
Date: Thursday 
Time: 10:00 am, Central Standard Time
Meeting number: 826 515 680 
Meeting password: 6gbpsSAS 
Agenda:
1. Proposed Cable Tables [McSorley]
Does above clarification in TxRx connection resolve budget issues?
2. Description of SSC profile allowed discontinuities. [Hernandez]
3. Interconnect Signal-to-Noise Ratio [Olawsky]
Add a SNR for the delivered signal at the receiver compliance point 
(system requirement)?
4. SAS-2 Receiver Device Physical Testing [Witt, Bari]
http://www.t10.org/ftp/t10/document.07/07-486r1.pdf
5. Refine/provide status on simulation technology. [Jenkins, Newman]
Alvin Cox
Seagate Technology, LLC
Cell 405-206-4809


From Elliott at hp.com  Wed Dec 12 12:19:20 2007
From: Elliott at hp.com (Elliott, Robert (Server Storage))
Date: Wed, 12 Dec 2007 20:19:20 +0000
Subject: SAS - Protocol-Specific Port log page
Message-ID: <mailman.820.1441607323.22512.t10@sandbox.t10.org>

Formatted message: <A HREF="r0712124_f.htm">HTML-formatted message</A>
Attachment #1: <A HREF="r0712124_image001.png">image001.png</A>
Attachment #2: <A HREF="r0712124_image002.png">image002.png</A>

________________________________
From: owner-t10 at t10.org [mailto:owner-t10 at t10.org] On Behalf Of Mike Berhan
Sent: Wednesday, December 12, 2007 12:49 PM
To: T10 at t10.org
Subject: SAS - Protocol-Specific Port log page
I am currently working with a SAS 1.1 device and reviewing the SAS-1.1 and
SAS-2 specification.  I have some questions / comments regarding the protocol
specific port log page for SAS.  Before I get to that, I need to provide some
simple screenshots of an actual SAS 1.1 device to help describe my question.
The first eight bytes of the "Protocol-Specific Port log parameter for SAS"
are similar between SAS-1.1 and SAS-2.	The SAS-1.1 decoding is below.	SAS-2
marks the "DS" bit as Obsolete, uses "Format and Linking" instead of "LBIN"
and "LP", and defines offset 6 as the "Generation Code."
[cid:003105519 at 12122007-2BCF]
An array of "SAS Phy Log Desriptor" entries follows this 8 byte header.  The
number of entries in the array is given to us in the "Number of Phys" entry
seen above.  OK, so far so good.
In reviewing SAS-1.1, the SAS phy log descriptor is a fixed 48 byte structure
as you see here:
[cid:003105519 at 12122007-2BD6]
Traversing through the array of SAS phy log descriptors is rather simple as
you know the number of Phys and you know that each descriptor is 48 bytes in
length.
The complexity comes with SAS-2.  This specification defines variable length
SAS phy log descriptors.  Offset 3 of the above structure is now defined as
the "SAS Phy Log Descriptor Length".  The structure is	larger than 48 bytes
and contains a variable number of Phy Event Descriptors.
In my task, I do not have the luxury of enumerating various information from
the device so I do not know if it's a SAS-1.1 or SAS-2 device.	All I have is
the log sense data to analyze.	I need to know if I'm looking at a SAS-1.1
descriptor or a SAS-2 descriptor.  The first method, or perhaps I should call
it a hack, that comes to mind is:
If ( DescriptorOffset[3]==0 )
   // It's a fixed 48 byte descriptor (i.e. SAS-1.1)
else
   // it's a variable length descriptor, total len = DescriptorOffset[3]+4
RE: That's the intended algorithm.  Always consider that byte to be a LENGTH
field, but special-case the length of 00h to mean 48 total bytes.
Now finally to my question.  If all I have access to is this log page, would
the above pseudo code be the preferred method of knowing which descriptor the
device is returning?  If not, is there another field in the descriptor that
would be preferred?  Should a "Version" field be introduced so that the
application layer knows which version of the structure they are looking at
and which fields are valid?
RE: T10 usually rejects Version fields; witness the response to 07-403r0.
Another question.  If I could enumerate more information from the device,
what would be the preferred way to detect a SAS-1.1 vs SAS-2 device from the
application layer?  Would the "Version Descriptors" in the Inquiry page be
the recommended method?
Thinking out loud, should SAS-2 introduce a new "cleaner" sub-page instead of
expanding the current page?  I am not a big fan of variable sized arrays
nested within other variable sized arrays.
RE: The page needs to report a variable number of events (vendor-specific)
for a variable number of phys (fixed by the hardware design) configured as a
variable number of ports (determined by what the phys happen to be attached
to); I don't think any other solution is going to be much cleaner.  The event
information could be given its own subpage, leaving the old page alone, but
log page subpages didn't even exist in SPC-4 until June 2006; the event
descriptors were added to SAS-2 in January 2006.
-------
Mike Berhan
busTRACE Technologies
9700 Village Center Drive
Suite 50-F
Granite Bay, CA  95746
916.773.4554 phone
916.218.6283 fax
http://www.bustrace.com


From Harry.Mason at lsi.com  Wed Dec 12 14:31:03 2007
From: Harry.Mason at lsi.com (Mason, Harry)
Date: Wed, 12 Dec 2007 15:31:03 -0700
Subject: [STA Members] STA Reception January 14th,
	CALL FOR PRESENTATIONS : Beyond SAS-2
Message-ID: <mailman.821.1441607323.22512.t10@sandbox.t10.org>

Formatted message: <A HREF="r0712125_f.htm">HTML-formatted message</A>

CALL FOR PRESENTATIONS
Being in the final stages of buttoning down the SAS-2, the SCSI Trade
Association would like to take the opportunity in Santa Ana, to discuss,
what comes next.  
Some are suggesting an interim specification to clean up SAS-2 and
possibly include additional cabling options.  Others are suggesting we
split the physical interface work from the SAS-3 standard development
effort.  I'm sure there are many other ideas on how to proceed and what
technologies should be considered in future SAS instantiations. 
All T10 and current STA members are invited to an open discussion on
this subject.
The reception will begin at 6:30pm on Monday January 14th at the Embassy
Suites in Santa Ana. .	Food and beverages will be provided. 
STA will make available up to six, 15 minute presentation slots, and the
topics are open to most anything we should be considering in future SAS
generations.
Please respond directly to clyon at scsita.org  with your presentation
topic and we'll add you to the agenda!
Looking forward to an informative and lively discussion
Thanks, 
Harry Mason
STA President
719-331-0994


From Harry.Mason at lsi.com  Wed Dec 12 14:31:03 2007
From: Harry.Mason at lsi.com (Mason, Harry)
Date: Wed, 12 Dec 2007 15:31:03 -0700
Subject: STA Reception January 14th, CALL FOR PRESENTATIONS : Beyond SAS-2
Message-ID: <mailman.822.1441607323.22512.t10@sandbox.t10.org>

Formatted message: <A HREF="r0712126_f.htm">HTML-formatted message</A>

CALL FOR PRESENTATIONS
Being in the final stages of buttoning down the SAS-2, the SCSI Trade
Association would like to take the opportunity in Santa Ana, to discuss,
what comes next.  
Some are suggesting an interim specification to clean up SAS-2 and
possibly include additional cabling options.  Others are suggesting we
split the physical interface work from the SAS-3 standard development
effort.  I'm sure there are many other ideas on how to proceed and what
technologies should be considered in future SAS instantiations. 
All T10 and current STA members are invited to an open discussion on
this subject.
The reception will begin at 6:30pm on Monday January 14th at the Embassy
Suites in Santa Ana. .	Food and beverages will be provided. 
STA will make available up to six, 15 minute presentation slots, and the
topics are open to most anything we should be considering in future SAS
generations.
Please respond directly to clyon at scsita.org  with your presentation
topic and we'll add you to the agenda!
Looking forward to an informative and lively discussion
Thanks, 
Harry Mason
STA President
719-331-0994


From mikeb at bustrace.com  Wed Dec 12 15:23:11 2007
From: mikeb at bustrace.com (Mike Berhan)
Date: Wed, 12 Dec 2007 15:23:11 -0800
Subject: SAS - Protocol-Specific Port log page
Message-ID: <mailman.823.1441607323.22512.t10@sandbox.t10.org>

* From the T10 Reflector (t10 at t10.org), posted by:
* "Mike Berhan" <mikeb at bustrace.com>
*
Robert,
Thank you for the detailed reply.
<<< RE: The page needs to report a variable number of events
(vendor-specific) for a variable number of phys (fixed by the hardware
design) configured as a variable number of ports (determined by what the
phys happen to be attached to); I don't think any other solution is going to
be much cleaner. >>>
I understand the need but this is one of the most complex pages I have seen.
In my experience, this complexity leads to more bugs in the firmware and in
the software trying to decode the data.  Certainly seems too late for any
drastic changes in this area and I know I'm late to the discussion on this
topic.	Thanks for listening.
By the way, if anyone is working on a SAS-2 device and wants to compare
their firmware return data with my software decoding, please contact me
privately.  We could help each other ensure proper compliance with the SAS-2
specification.	I wouldn't need your hardware.
-------
Mike Berhan
busTRACE Technologies
9700 Village Center Drive
Suite 50-F
Granite Bay, CA? 95746
916.773.4554 phone
916.218.6283 fax
http://www.bustrace.com
*
* For T10 Reflector information, send a message with
* 'info t10' (no quotes) in the message body to majordomo at t10.org


From roweber at IEEE.org  Wed Dec 12 20:19:41 2007
From: roweber at IEEE.org (Ralph Weber)
Date: Wed, 12 Dec 2007 22:19:41 -0600
Subject: 07-169r4 -- ESP-SCSI for Parameter Data
Message-ID: <mailman.824.1441607323.22512.t10@sandbox.t10.org>

* From the T10 Reflector (t10 at t10.org), posted by:
* Ralph Weber <roweber at ieee.org>
*
A new revision of ESP-SCSI for Parameter Data has been uploaded
in preparation for next weeks Security Conference call.
http://www.t10.org/ftp/t10/document.07/07-169r4.pdf
Happy reviewing,
.Ralph
*
* For T10 Reflector information, send a message with
* 'info t10' (no quotes) in the message body to majordomo at t10.org


From gop at us.ibm.com  Thu Dec 13 11:03:07 2007
From: gop at us.ibm.com (George Penokie)
Date: Thu, 13 Dec 2007 13:03:07 -0600
Subject: Reminder of SAM-4 letter ballot resolution meeting this Friday
Message-ID: <mailman.825.1441607323.22512.t10@sandbox.t10.org>

Formatted message: <A HREF="r0712130_f.htm">HTML-formatted message</A>

This a reminder of the SAM-4 letter ballot meeting that will be held this 
Friday (12/14). Meeting informatin is as follows:
12/14/2007 - 10:00 am - noon (central time) 
Audio Conference Access Numbers
USA: 770-615-1254 (Note: this number may be a problem in some locations), 
Tie-Line 421-0038 or 1-877-421-0038
Passcode: 198458 
The webex information of the call on 12/14/2007 is as follows: 
Topic: SAM-4 Letter Ballot 
Date: Friday, December 14, 2007 
Time: 10:00 am, Central Standard Time (GMT -06:00, Chicago ) 
Meeting Number: 570 547 640 
Meeting Password: Resolve 
Please click the link below to see more information, or to join the 
meeting. 
------------------------------------------------------- 
To join the online meeting 
------------------------------------------------------- 
1. Go to https://lsilogic.webex.com/lsilogic/j.php?ED=102386652&UID=0 
2. Enter your name and email address. 
3. Enter the meeting password: Resolve 
4. Click "Join". 
Bye for now,
George Penokie
Dept 9A8 030-3 A410
E-Mail:    gop at us.ibm.com
Internal:  553-5208


From plavarre at lexar.com  Thu Dec 13 12:50:54 2007
From: plavarre at lexar.com (plavarre at lexar.com)
Date: Thu, 13 Dec 2007 12:50:54 -0800
Subject: SPC Inquiry for Quad-Aligned Zero -- deprecated since SPC-4 maybe
Message-ID: <mailman.826.1441607323.22512.t10@sandbox.t10.org>

* From the T10 Reflector (t10 at t10.org), posted by:
* <plavarre at lexar.com>
*
> > http://t10.org/ftp/t10/drafts/spc4/spc4r11.pdf
> > should be should be
Thanks for pointing out that SPC-4 editing error. I didn't see it when I
copy-pasted into here.
Adobe Reader here finds the string "should be should be" only at that
place in all of that 2007 May 14 R11 draft.
Is SPC-4 still new enough we can fix such tupographical errors, or is
this an SPC-5 fix?
> Those are just ...
As for the additional gift of this substantive reply, ouch as yet I'm
missing something sorry.
The tone was disagreement, but all the detail is agreement, so far as I
can see?
So I'll try to explain again, but I'll take care to cite "shall"s, not
only the "should"s, to give a more complete picture ...
> > > http://t10.org/ftp/t10/drafts/spc4/spc4r11.pdf
> > > 4.3 CDB ... 4.3.4 Common CDB fields ... 4.3.4.6 Allocation length
...
> > > ...
> > > An allocation length of zero specifies
> > > that no data shall be transferred.
> > > This condition shall not be considered as an error.
That's the "shall" that Rob found.
> > http://t10.org/ftp/t10/drafts/spc4/spc4r11.pdf
> > 6.4 INQUIRY command ...
> >
> > the allocation length should be should be at least four, so that ...
> > ... parameter data ... is returned.
That's our "should".
> > Do we actually now mean to be so explicitly deprecating the SCSI
test 
> > tradition of SPC Inquiry for zero?
I trust we agree, yes we actually have explicitly deprecated a tradition
whenever, alongside a device "shall" implement, we also publish a host
"should not" send.
So far so good for citing duplicate context that we definitely hold in
common?
> > SPC Inquiry for Quad-Aligned Zero ...
> > "12 00 00 00 00 00" ... six byte hex CDB ...
That popular test command plainly violates this "should".
The two bytes at offset three are zero, thus the Allocation Length is
zero, thus the Allocation Length is not "at least four", thus that
command plainly is a command that the host "should not" send.
Yes?
> Those are just "should" not "shall" rules,
Yes.
> so zero doesn't violate them.
Whoa. Do we agree here also now? I'd say both yes and no.
I'm thinking this zero does violate the "should" rules and does not
violate the "shall" rules.
I'm thinking this zero thus moves this host into the "should not"
category, without giving permission to the device to become a "shall
not" device.
I think that's unfortunate -- accidental -- not what we mean -- like
typing "should be should be" to mean "should be".
No?
Tell me yes and I'll propose corrected language. Tell me No and I'll
learn something essential and new.
> The sentences explain why the advice is provided
Yes.
> a value less than 4 or 5 results in a truncated LENGTH field, which
could be misinterpreted.
Yes.
Furthermore, a value of zero results in an entirely absent EVPD 0
Additional Length or EVPD 1 Page Length field, which is even more likely
to be misunderstood, especially by hosts that neglect our should rule of
zero the data buffer before executing any non-time-critical command to
copy data into the buffer. (Not that I have the least clue where we hide
that rule in SAM either.)
> The general ALLOCATION LENGTH field definition in 4.3.4.6
> (used by most but not all commands that have a field with that name)
> specifically says zero is not an error.
> INQUIRY uses the 4.3.4.6 definition.
This is more context for our "shall". I agree.
Spc4r11.pdf 14 May 2007 6.4 "INQUIRY command" cites 4.3.4.6 yes.
Mmc6r01.pdf 24 October 2007 6.8 "INQUIRY command" cites SPC-3. Close
enough.
Those are all the current competing redefinitions of INQUIRY published
by T10.org known to me.
> > where our 
> > language is that recommends SPC Inquiry Allocation Lengths be 
> > quad-aligned for SCSI transports that require quad-aligned data 
> > phases?
>
> The SCSI Architecture Model requires SCSI transports to support byte
precision for transfer lengths.
De jure, that's the theory we publish at T10.org, ok.
De facto, massively many instances of hosts and devices actually don't
follow that rule. I've got war stories in SPI, in SCSI thru ATA (ATAPI),
in FireWire. For FireWire I remember seeing Apple & Microsoft coordinate
to define a new FireWire descriptor to say hey this device implements
all of SBP-2 Normative Annex B except not that part of SAM.
Not good for my Windows storage peripheral industry to have the theory
flat wrong so massively often.
> The wording in SAM-4 revision 13b section 5.4.3.1 is:
> "All SCSI transport protocol standards shall define support
> for a resolution of one byte for the Application Client Buffer Size
argument."
Thank you! I hadn't found that. Now I know what to cite when I complain
of this mob rule in particular.
> It allows transports to ensure
> that interim transfers are aligned on larger boundaries,
> as long as the last transfer can deliver any specific number of bytes:
Cool.
> "SCSI transport protocol standards may define restrictions
> on the resolution of the Application Client Buffer Offset argument.
Ah. Next question if I may:
For transports that share memory addresses between host and device --
such as FireWire -- does this sentence allow the device to require the
host to align its memory address, or vice versa?
> SCSI transport protocol standards may define restrictions
> on the resolution of the Request Byte Count argument
> for any call to Send Data-In or any call to Receive Data-Out
> that does not transfer the last byte of the Application Client
Buffer."
Aye, crystal clear, I thank you again.
I see this is the same theory as the ATAPI claim that any number of
bytes can cross the bus two bytes at a time, with maybe an odd byte at
the end. Works great any time both host and device bother to support it.
> ...
Most curiously yours, thanks again,
*
* 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  Thu Dec 13 13:56:43 2007
From: lohmeyer at t10.org (John Lohmeyer)
Date: Thu, 13 Dec 2007 14:56:43 -0700
Subject: Please check your spam filters
Message-ID: <mailman.827.1441607323.22512.t10@sandbox.t10.org>

* From the T10 Reflector (t10 at t10.org), posted by:
* John Lohmeyer <lohmeyer at t10.org>
*
T10 voting members:
Please make sure that your spam filters do not block emails from the address:
   scsi.bbs at lsi.com
Sometimes this can be accomplished by putting this address in your email
address book or by placing it on a 'white list'. This email address is used
by several pieces of automation on the T10 web site to send you things like
document numbers and letter ballot notifications.
Thanks,
John
--
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 roger_cummings at symantec.com  Fri Dec 14 11:10:17 2007
From: roger_cummings at symantec.com (Roger Cummings)
Date: Fri, 14 Dec 2007 12:10:17 -0700
Subject: Persistent Reservation Proposal - Group Reservations
Message-ID: <mailman.828.1441607323.22512.t10@sandbox.t10.org>

Formatted message: <A HREF="r0712140_f.htm">HTML-formatted message</A>

Kevin,
First of all, let me say that I completely support what you're trying to
do here. I think that providing a method in persistent reservations
(PRs) to support shared access between ONLY a specifically-designated
set of systems is a worthy goal, and something we should do in SPC-4.
Adding a set of Transport IDs to Reserve as per your document 08-024 &
08-025 is certainly possible, but it's a massive change to the way that
PRs work today, and it throws up a bunch of nasty corner cases and
backwards compatibility issues.
The massive change comes from the fact that now the Target will have to
remember which registrations are in the Reservation, and which are not.
It will probably have to preserve all of the transport information for
the life of the reservation.
The corner cases are things like, what happens if there's no longer a
registration that corresponds to the transport ID in the Reserve? Does
the Reserve succeed? What happens if a registration comes in later,
after the reservation has been established - does that device it get
access?
Backwards compatibility issues may arise like this: An existing device
registers, and finds it has no access, so it does a PR In and finds out
that a reservation is in place, retries its access and still it has no
access. What does it do next, preempt the reservation because it assumes
the Target is broken?
Reserve also has to be an "atomic" command, and I've always thought that
was why it's functionality is as compact as it is today. Most of the
complex operations related to addresses and keys are done at
registration time, and those operations don't have to be atomic.
One more thing: you chose for your new "group" reservations to follow
the "all registrants" approach is terms of the definition of the
reservation holder. While that's fine by me (obviously), I suspect there
are also situations where group reservations that follow the
"registrants only" approach might be useful.
The bottom line from my point of view is this: Your proposal is feasible
and we can probably make it work. But I wonder if there's an easier way
to achieve the same goal that is more compatible with existing practice
and requires less of a change in functionality on the Target side.
What if we didn't add any new reservations types, but instead added some
new functionality to the registration process? What I'm thinking of a
new Register feature that causes the Target to kill all existing
registrations, create the registrations identified in the transport IDs
in the Register command, and not accept any future registrations. That
way, we don't need any changes to Reserve, and an Initiator with
existing functionality would just not be able to register and therefore
would not be confused.
Does that make sense to you? Is there a chance this is an easier
approach? If so, I'll write up a detailed proposal that's the equivalent
of 08-025r0 and we can compare and contrast at the next CAP.
Again, thanks for getting this started, I think it's a worthwhile
endeavor and I'll be glad to put some cycles towards defining this sort
of functionality for SPC-4.
Regards,
Roger
________________________________
	From: owner-t10 at t10.org [mailto:owner-t10 at t10.org] On Behalf Of
Kevin D Butt
	Sent: Monday, December 10, 2007 4:18 PM
	To: t10 at t10.org
	Subject: Persistent Reservation Proposal - Group Reservations
	I have posted two documents related to an additional Persistent
Reservation Type.  The first document is a presentation on where
persistent reservations are today and where they fall short in the
scenarios covered by the proposal.  It also covers the intent of the
proposal and what will be proposed.  The second is the actual proposal 
	Your PDF file will be posted at:
	  http://www.t10.org/ftp/t10/document.08/08-024r0.pdf 
	   http://www.t10.org/ftp/t10/document.08/08-025r0.pdf
	Normally, the posting/archiving process takes about 30 minutes. 
	Kevin D. Butt
	SCSI & Fibre Channel Architect, Tape Firmware, IBM
	MS 6TYA, 9000 S. Rita Rd., Tucson, AZ 85744
	Tel: 520-799-2869 / 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 curtis.ballard at hp.com  Fri Dec 14 15:23:45 2007
From: curtis.ballard at hp.com (Ballard, Curtis C (StorageWorks))
Date: Fri, 14 Dec 2007 23:23:45 +0000
Subject: Automation Encryption Control 07-164r9 revised and posted as
 08-029r0
Message-ID: <mailman.829.1441607323.22512.t10@sandbox.t10.org>

* From the T10 Reflector (t10 at t10.org), posted by:
* "Ballard, Curtis C (StorageWorks)" <curtis.ballard at hp.com>
*
I have revised 07-164r9 with the comments from the December 12th ADI
conference call and posted it under the new number 08-029r0 at the below
link.
There has been one technical change request since the meeting in the
Encryption Algorithm Support descriptor, section 6.3.5.2, page 21, table
y+15.  I had moved the DISABLE bit since the last revision and we did not
discuss the new location in the call.  After the call I had a request to move
the bit to the other end of the same byte.  I don't have any issue with the
proposed location so I have made that change.
Comments before the January meeting are encouraged.
Curtis Ballard
Hewlett Packard
------------------------
2007/12/14 16:13:16
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/ftp/t10/document.08/08-029r0.pdf
Normally, the posting/archiving process takes about 30 minutes.
Please contact John Lohmeyer <lohmeyer at t10.org>
should you need further assistance.
*
* For T10 Reflector information, send a message with
* 'info t10' (no quotes) in the message body to majordomo at t10.org


From keiji_katata at post.pioneer.co.jp  Fri Dec 14 18:32:27 2007
From: keiji_katata at post.pioneer.co.jp (keiji_katata at post.pioneer.co.jp)
Date: Sat, 15 Dec 2007 11:32:27 +0900
Subject: Posted: Agenda proposal
Message-ID: <mailman.830.1441607323.22512.t10@sandbox.t10.org>

* From the T10 Reflector (t10 at t10.org), posted by:
* keiji_katata at post.pioneer.co.jp
*
Hello all,
I posted agenda proposal document on ftp.
ftp.avc-pioneer.com/Mtfuji_7/Proposal/Dec07/Agenda Dec07.doc
Best regards,
Keiji Katata
PIONEER CORP.
*
* For T10 Reflector information, send a message with
* 'info t10' (no quotes) in the message body to majordomo at t10.org


From Elliott at hp.com  Sat Dec 15 11:12:25 2007
From: Elliott at hp.com (Elliott, Robert (Server Storage))
Date: Sat, 15 Dec 2007 19:12:25 +0000
Subject: 08-031 StatEye v5.071210 results
Message-ID: <mailman.831.1441607323.22512.t10@sandbox.t10.org>

* From the T10 Reflector (t10 at t10.org), posted by:
* "Elliott, Robert (Server Storage)" <Elliott at hp.com>
*
08-031r0 is now posted on http://www.t10.org/new.htm, compiling results from
running StatEye v5.071210 on the T10 channel models (HP01-14, 24-28, and 0.5,
1, 3, 6, 10 m Mini SAS cables).  The .pdf file is just an overview; the .zip
file includes an Excel spreadsheet with the detailed results.
The .zip file also includes two python files to replace testcase.py that can
spawn simulations with all possible combinations of selected parameters
(e.g., .s4p filename, DFE taps, deemphasis values, 8b10b coding/random data,
baud rate).  The outer layer program (metatest) sends the parameters to the
inner layer program  (test-sub) by command-line arguments.
StatEye is available on
http://www.stateye.org/developmentForum/doku.php?id=v5.0.0.
To run StatEye, you need to first install the python interpreter and the
support modules listed on
http://www.stateye.org/developmentForum/doku.php?id=python.  For Windows,
that means you should download and install these files:
  python-2.5.1.msi
  ipython-0.8.1.win32.exe
  pyreadline-1.4.4.win32.exe
  numpy-1.0.4.win32-py2.5.msi
  scipy-0.6.0.win32-py2.5.exe
  matplotlib-0.90.1.win32-py2.5.exe
  pywin32-210.win32-py2.5.exe
--
Rob Elliott, elliott at hp.com
Hewlett-Packard Industry Standard Server Storage Advanced Technology
*
* 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  Sat Dec 15 23:00:41 2007
From: lohmeyer at t10.org (T10 Document Administrator)
Date: Sun, 16 Dec 2007 00:00:41 -0700
Subject: Recent T10 documents uploaded since 2007/12/09
Message-ID: <mailman.832.1441607323.22512.t10@sandbox.t10.org>

* From the T10 Reflector (t10 at t10.org), posted by:
* T10 Document Administrator <lohmeyer at t10.org>
*
Proposals
---------
Automation encryption control
(by: Curtis Ballard)
T10/07-164r9   Uploaded: 2007/12/11   192613 bytes
ftp://ftp.t10.org/t10/document.07/07-164r9.pdf
ESP-SCSI for Parameter Data
(by: Ralph O. Weber)
T10/07-169r4   Uploaded: 2007/12/12   100475 bytes
ftp://ftp.t10.org/t10/document.07/07-169r4.pdf
SAT-2 WRITE LONG to WRITE UNCORRECTABLE EXT
(by: Rob Elliott and Jeff Wolford)
T10/07-200r3   Uploaded: 2007/12/10   86769 bytes
ftp://ftp.t10.org/t10/document.07/07-200r3.pdf
SAS-2: Limiting SAS Target response to OPEN_REJECT (RETRY)
(by: George O. Penokie)
T10/07-391r2   Uploaded: 2007/12/14   209535 bytes
ftp://ftp.t10.org/t10/document.07/07-391r2.pdf
Results of letter ballot on forwarding SES-2 to first public review
(by: John Lohmeyer)
T10/07-512r0   Uploaded: 2007/12/13   257914 bytes
ftp://ftp.t10.org/t10/document.07/07-512r0.pdf
Results of letter ballot on forwarding NWIP on SAM-4
(by: John Lohmeyer)
T10/07-514r0   Uploaded: 2007/12/13   28240 bytes
ftp://ftp.t10.org/t10/document.07/07-514r0.pdf
SAS-2: SP State Machine - SL State Machine interaction issue
(by: William Martin)
T10/08-010r0   Uploaded: 2007/12/11   31925 bytes
ftp://ftp.t10.org/t10/document.08/08-010r0.pdf
Minutes: ADI Teleconference 12 December 2007
(by: Michael Banther)
T10/08-013r0   Uploaded: 2007/12/12   19728 bytes
ftp://ftp.t10.org/t10/document.08/08-013r0.pdf
SAS-2: Remove restrictions for SSC
(by: Gerald Houlder)
T10/08-014r0   Uploaded: 2007/12/12   14181 bytes
ftp://ftp.t10.org/t10/document.08/08-014r0.pdf
SAS: Add low power transceiver options
(by: Gerald Houlder)
T10/08-015r0   Uploaded: 2007/12/12   20742 bytes
ftp://ftp.t10.org/t10/document.08/08-015r0.pdf
SAT-2 Add translation for Block Characteristics VPD Page
(by: Brad Besmer)
T10/08-016r1   Uploaded: 2007/12/10   75084 bytes
ftp://ftp.t10.org/t10/document.08/08-016r1.pdf
Minutes of SAT-2 Working Group - December 10, 2007
(by: Lohmeyer & Overby)
T10/08-017r0   Uploaded: 2007/12/10   35111 bytes
ftp://ftp.t10.org/t10/document.08/08-017r0.htm
Minutes of SAT-2 Working Group - December 10, 2007
(by: Lohmeyer & Overby)
T10/08-017r0   Uploaded: 2007/12/10   103325 bytes
ftp://ftp.t10.org/t10/document.08/08-017r0.pdf
SAT-2: Non-volatile cache translation
(by: Mark Overby)
T10/08-018r0   Uploaded: 2007/12/10   93822 bytes
ftp://ftp.t10.org/t10/document.08/08-018r0.pdf
SAT-2 WRITE BUFFER MODE 7 to DOWNLOAD MICROCODE Mode 3
(by: Jeff Wolford)
T10/08-019r0   Uploaded: 2007/12/10   73170 bytes
ftp://ftp.t10.org/t10/document.08/08-019r0.pdf
ADC-3 Automation Device Serial Number subpage
(by: Rod Wideman)
T10/08-021r0   Uploaded: 2007/12/11   144762 bytes
ftp://ftp.t10.org/t10/document.08/08-021r0.pdf
SSC-3 Automation device serial number VPD page
(by: Rod Wideman)
T10/08-022r0   Uploaded: 2007/12/11   135807 bytes
ftp://ftp.t10.org/t10/document.08/08-022r0.pdf
SAT-2: Open Issues List
(by: Mark Overby)
T10/08-023r0   Uploaded: 2007/12/10   19530 bytes
ftp://ftp.t10.org/t10/document.08/08-023r0.pdf
SPC-4: Group Persistent Reservations - Presentation
(by: Kevin Butt)
T10/08-024r0   Uploaded: 2007/12/10   112947 bytes
ftp://ftp.t10.org/t10/document.08/08-024r0.pdf
SPC-4: Group Persistent Reservations - Proposal
(by: Kevin Butt)
T10/08-025r0   Uploaded: 2007/12/10   337039 bytes
ftp://ftp.t10.org/t10/document.08/08-025r0.pdf
SES-2 Element control and status nomenclature
(by: Rob Elliott)
T10/08-026r0   Uploaded: 2007/12/12   183667 bytes
ftp://ftp.t10.org/t10/document.08/08-026r0.pdf
Toward_SSC_Modulation_Specs_and_Link_Budget.pdf
(by: Rick Hernandez Guillaume Fortin)
T10/08-027r0   Uploaded: 2007/12/13   288706 bytes
ftp://ftp.t10.org/t10/document.08/08-027r0.pdf
Toward_SSC_Modulation_Specs_and_Link_Budget.pdf
(by: Rick Hernandez Guillaume Fortin)
T10/08-027r1   Uploaded: 2007/12/13   944874 bytes
ftp://ftp.t10.org/t10/document.08/08-027r1.pdf
Automation encryption control
(by: Curtis Ballard)
T10/08-029r0   Uploaded: 2007/12/14   188636 bytes
ftp://ftp.t10.org/t10/document.08/08-029r0.pdf
Letter Ballot Jeopardy - December 14, 2007
(by: John Lohmeyer)
T10/08-030r0   Uploaded: 2007/12/14   96765 bytes
ftp://ftp.t10.org/t10/document.08/08-030r0.pdf
SAS-2 StatEye v5.071210 results
(by: Rob Elliott)
T10/08-031r0   Uploaded: 2007/12/14   19623 bytes
ftp://ftp.t10.org/t10/document.08/08-031r0.pdf
SAS-2 StatEye v5.071210 results
(by: Rob Elliott)
T10/08-031r0   Uploaded: 2007/12/14   40785 bytes
ftp://ftp.t10.org/t10/document.08/08-031r0.zip
Working Drafts
--------------
(Report generated on 2007/12/16 at 00:00:40)
*
* For T10 Reflector information, send a message with
* 'info t10' (no quotes) in the message body to majordomo at t10.org


From kdbutt at us.ibm.com  Mon Dec 17 06:51:24 2007
From: kdbutt at us.ibm.com (Kevin D Butt)
Date: Mon, 17 Dec 2007 07:51:24 -0700
Subject: Persistent Reservation Proposal - Group Reservations
Message-ID: <mailman.833.1441607323.22512.t10@sandbox.t10.org>

Formatted message: <A HREF="r0712170_f.htm">HTML-formatted message</A>

Roger,
Thank you for your feedback.  I am certainly willing to entertain  other 
methods for accomplishing the end goal in an easier fashion.  I am not 
sure I understand how your proposed method makes it more backward 
compatible.  In my proposal PRin would show a different type of 
reservation and hence the application clients would not try to join the 
reservation because they don't know about the type.  In your proposal, 
application clients would not be allowed to register.  This is a deviation 
|from what they can always do today - unless there is a resource issue. 
This seems more disruptive to me.  I would assume that there would be a 
new additional sense code added for UNABLE TO REGISTER BECAUSE A GROUP 
RESERVATION IS IN PLACE (or analogous).  This would be a new thing for 
failure to register and there would be pain at the register point. Perhaps 
that is better than at the reserve point - but I would think that it would 
be better handled as a reservation conflict since that is what it is 
instead of something the application client does not understand.
As for "all registrants" type vs. "registrants only" I didn't see where 
the difference would be interesting, but I am not opposed to providing a 
way to switch between which of these two types is done.  Whether it is 
additional types or some bit during registration etc.
As for some of the corner cases mentioned below, if each I_T nexus that is 
supposed to be part of the group reservation is required to be registered 
before the reservation is made, and if the reservation is released when 
the last group reservation participant is unregistered, then I think we 
don't have an issue.
I would prefer that we work together to shape a mutually beneficial 
proposal as opposed to have "competing" proposals.  I am willing to modify 
my proposal where it can be made easier and such.  I am not sold that my 
proposed method is the only way or even the best - it's just the way I 
thought of doing it.  I admit that I have always been very confused about 
the usefulness of RA and AR types.  They make absolutely no sense in the 
tape world.
Thanks,
Kevin D. Butt
SCSI & Fibre Channel Architect, Tape Firmware
MS 6TYA, 9000 S. Rita Rd., Tucson, AZ 85744
Tel: 520-799-2869 / 520-799-5280
Fax: 520-799-2723 (T/L:321)
Email address: kdbutt at us.ibm.com
http://www-03.ibm.com/servers/storage/ 
"Roger Cummings" <roger_cummings at symantec.com> 
Sent by: owner-t10 at t10.org
12/14/2007 12:10 PM
To
Kevin D Butt/Tucson/IBM at IBMUS
cc
<t10 at t10.org>
Subject
RE: Persistent Reservation Proposal - Group Reservations
Kevin,
First of all, let me say that I completely support what you're trying to 
do here. I think that providing a method in persistent reservations (PRs) 
to support shared access between ONLY a specifically-designated set of 
systems is a worthy goal, and something we should do in SPC-4.
Adding a set of Transport IDs to Reserve as per your document 08-024 & 
08-025 is certainly possible, but it's a massive change to the way that 
PRs work today, and it throws up a bunch of nasty corner cases and 
backwards compatibility issues.
The massive change comes from the fact that now the Target will have to 
remember which registrations are in the Reservation, and which are not. It 
will probably have to preserve all of the transport information for the 
life of the reservation.
The corner cases are things like, what happens if there's no longer a 
registration that corresponds to the transport ID in the Reserve? Does the 
Reserve succeed? What happens if a registration comes in later, after the 
reservation has been established - does that device it get access?
Backwards compatibility issues may arise like this: An existing device 
registers, and finds it has no access, so it does a PR In and finds out 
that a reservation is in place, retries its access and still it has no 
access. What does it do next, preempt the reservation because it assumes 
the Target is broken?
Reserve also has to be an "atomic" command, and I've always thought that 
was why it's functionality is as compact as it is today. Most of the 
complex operations related to addresses and keys are done at registration 
time, and those operations don't have to be atomic.
One more thing: you chose for your new "group" reservations to follow the 
"all registrants" approach is terms of the definition of the reservation 
holder. While that's fine by me (obviously), I suspect there are also 
situations where group reservations that follow the "registrants only" 
approach might be useful.
The bottom line from my point of view is this: Your proposal is feasible 
and we can probably make it work. But I wonder if there's an easier way to 
achieve the same goal that is more compatible with existing practice and 
requires less of a change in functionality on the Target side.
What if we didn't add any new reservations types, but instead added some 
new functionality to the registration process? What I'm thinking of a new 
Register feature that causes the Target to kill all existing 
registrations, create the registrations identified in the transport IDs in 
the Register command, and not accept any future registrations. That way, 
we don't need any changes to Reserve, and an Initiator with existing 
functionality would just not be able to register and therefore would not 
be confused.
Does that make sense to you? Is there a chance this is an easier approach? 
If so, I'll write up a detailed proposal that's the equivalent of 08-025r0 
and we can compare and contrast at the next CAP.
Again, thanks for getting this started, I think it's a worthwhile endeavor 
and I'll be glad to put some cycles towards defining this sort of 
functionality for SPC-4.
Regards,
Roger
From: owner-t10 at t10.org [mailto:owner-t10 at t10.org] On Behalf Of Kevin D 
Butt
Sent: Monday, December 10, 2007 4:18 PM
To: t10 at t10.org
Subject: Persistent Reservation Proposal - Group Reservations
I have posted two documents related to an additional Persistent 
Reservation Type.  The first document is a presentation on where 
persistent reservations are today and where they fall short in the 
scenarios covered by the proposal.  It also covers the intent of the 
proposal and what will be proposed.  The second is the actual proposal 
Your PDF file will be posted at:
  http://www.t10.org/ftp/t10/document.08/08-024r0.pdf 
   http://www.t10.org/ftp/t10/document.08/08-025r0.pdf
Normally, the posting/archiving process takes about 30 minutes. 
Kevin D. Butt
SCSI & Fibre Channel Architect, Tape Firmware, IBM
MS 6TYA, 9000 S. Rita Rd., Tucson, AZ 85744
Tel: 520-799-2869 / 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 gop at us.ibm.com  Mon Dec 17 07:25:45 2007
From: gop at us.ibm.com (George Penokie)
Date: Mon, 17 Dec 2007 09:25:45 -0600
Subject: Todays meeting information
Message-ID: <mailman.834.1441607323.22512.t10@sandbox.t10.org>

Formatted message: <A HREF="r0712171_f.htm">HTML-formatted message</A>

This a reminder of the SAM-4 letter ballot meeting that will be held today 
(12/17). Meeting informatin is as follows: 
12/17/2007 - 10:00 am - noon (central time) 
Audio Conference Access Numbers
USA: 770-615-1254 (Note: this number may be a problem in some locations), 
Tie-Line 421-0038 or 1-877-421-0038
Passcode: 198458 
The video information of the call on 12/17/2007 is as follows: 
Presenter key 
EHT66EHH8B
https://<a href="http://www.rooms.hp.com/attend/default.aspx?key=EHT66EHH8B">www.rooms.hp.com/attend/default.aspx?key=EHT66EHH8B 
Participant key 
EPHP2H7QZ9
https://<a href="http://www.rooms.hp.com/attend/default.aspx?key=EPHP2H7QZ9">www.rooms.hp.com/attend/default.aspx?key=EPHP2H7QZ9 
Bye for now,
George Penokie
Dept 9A8 030-3 A410
E-Mail:    gop at us.ibm.com
Internal:  553-5208


From kdbutt at us.ibm.com  Mon Dec 17 12:53:57 2007
From: kdbutt at us.ibm.com (Kevin D Butt)
Date: Mon, 17 Dec 2007 13:53:57 -0700
Subject: Persistent Reservation Proposal - Group Reservations
Message-ID: <mailman.835.1441607323.22512.t10@sandbox.t10.org>

Formatted message: <A HREF="r0712172_f.htm">HTML-formatted message</A>

Fred,
This is being proposed for SPC.
There are multiple types of reservations.  In an environment where one 
node of a cluster must join later, one of the other types can be used. 
Either that or have an existing node in your cluster add the new node. The 
whole intent of this Group reservation is to lock out everybody that is 
not explicitly specified during the reserve.  We have made provisions for 
adding members once the reservation exists, but only one of the 
reservation holders can add another entity.  The new entity cannot add 
itself.  This is the whole point of reservations (i.e., lock out others 
|from doing stuff while I think I have exclusive rights).
To put it in other word's, to allow somebody to join the reservation of 
their own accord without permission is EXACTLY what I am trying to protect 
against.
Thanks,
Kevin D. Butt
SCSI & Fibre Channel Architect, Tape Firmware
MS 6TYA, 9000 S. Rita Rd., Tucson, AZ 85744
Tel: 520-799-2869 / 520-799-5280
Fax: 520-799-2723 (T/L:321)
Email address: kdbutt at us.ibm.com
http://www-03.ibm.com/servers/storage/ 
"Knight, Frederick" <Frederick.Knight at netapp.com> 
12/17/2007 01:38 PM
To
Kevin D Butt/Tucson/IBM at IBMUS
cc
Subject
RE: Persistent Reservation Proposal - Group Reservations
Sorry, you can't require everyone to register before the reserve.
That's like saying my whole cluster can't boot because 1 node is down. You 
need
to have a way for a "down" initiator to join the fun after the fact.
I helped write a host cluster product that used a shared tape (failover 
model).  The
backup application would write to the tape.  If a system failure ever 
happened, the
backup application would failover to a different host.	It would skip 
backwards on
the tape for a few records, recognize where it left off, and then resume 
operation.
BUT, for some protection, we used reservations to make sure only 1 
initiator at a
time could access the tape.  The interesting point however, is that we 
were in the
process of upgrading from old SCSI-2 RESERVE to using PR.  Because, we 
also
have multiple HBAs in the host, and we wanted to be able to use more than 
1 of
those HBAs (so we needed multiple reservations - aka PR).  Having this 
idea
(group reservations) would have been a real nice addition.
As for the RA/AR differences.  It seemed to be timing.	Registrants Only 
was fairly
early on (as I remember), and so implemented by several O/S vendors. Later 
on,
some issues were found (which got complicated spec-ees added to address), 
but also,
the All Registrants was added (which didn't have those issues).  But, 
since there were
implementations, it couldn't be removed like the other old PR types that 
no one ever
used.  Anyway, I agree, they offer basically the same capabilities, but RO 
is already
out there, and AR is probably what new implementers are using (it's easier 
to understand
and implement from the host side).  Most of the differences are already 
documented,
so there wouldn't be that much extra for you to write to have both types 
(which I think
would be better than bit somewhere - do it the same way all the others are 
done).	But,
you could also just do the AR version, and let someone else add the RO 
version if they
want it.
Are you proposing this for tape only? or SPC in general?  I assume SPC in 
general.
    Fred Knight
From: Kevin D Butt [mailto:kdbutt at us.ibm.com] 
Sent: Monday, December 17, 2007 9:51 AM
To: Roger Cummings
Cc: t10 at t10.org
Subject: RE: Persistent Reservation Proposal - Group Reservations
Roger, 
Thank you for your feedback.  I am certainly willing to entertain  other 
methods for accomplishing the end goal in an easier fashion.  I am not 
sure I understand how your proposed method makes it more backward 
compatible.  In my proposal PRin would show a different type of 
reservation and hence the application clients would not try to join the 
reservation because they don't know about the type.  In your proposal, 
application clients would not be allowed to register.  This is a deviation 
|from what they can always do today - unless there is a resource issue. 
This seems more disruptive to me.  I would assume that there would be a 
new additional sense code added for UNABLE TO REGISTER BECAUSE A GROUP 
RESERVATION IS IN PLACE (or analogous).  This would be a new thing for 
failure to register and there would be pain at the register point. Perhaps 
that is better than at the reserve point - but I would think that it would 
be better handled as a reservation conflict since that is what it is 
instead of something the application client does not understand. 
As for "all registrants" type vs. "registrants only" I didn't see where 
the difference would be interesting, but I am not opposed to providing a 
way to switch between which of these two types is done.  Whether it is 
additional types or some bit during registration etc. 
As for some of the corner cases mentioned below, if each I_T nexus that is 
supposed to be part of the group reservation is required to be registered 
before the reservation is made, and if the reservation is released when 
the last group reservation participant is unregistered, then I think we 
don't have an issue. 
I would prefer that we work together to shape a mutually beneficial 
proposal as opposed to have "competing" proposals.  I am willing to modify 
my proposal where it can be made easier and such.  I am not sold that my 
proposed method is the only way or even the best - it's just the way I 
thought of doing it.  I admit that I have always been very confused about 
the usefulness of RA and AR types.  They make absolutely no sense in the 
tape world. 
Thanks, 
Kevin D. Butt
SCSI & Fibre Channel Architect, Tape Firmware
MS 6TYA, 9000 S. Rita Rd., Tucson, AZ 85744
Tel: 520-799-2869 / 520-799-5280
Fax: 520-799-2723 (T/L:321)
Email address: kdbutt at us.ibm.com
http://www-03.ibm.com/servers/storage/ 
"Roger Cummings" <roger_cummings at symantec.com> 
Sent by: owner-t10 at t10.org 
12/14/2007 12:10 PM 
To
Kevin D Butt/Tucson/IBM at IBMUS 
cc
<t10 at t10.org> 
Subject
RE: Persistent Reservation Proposal - Group Reservations
Kevin, 
First of all, let me say that I completely support what you're trying to 
do here. I think that providing a method in persistent reservations (PRs) 
to support shared access between ONLY a specifically-designated set of 
systems is a worthy goal, and something we should do in SPC-4. 
Adding a set of Transport IDs to Reserve as per your document 08-024 & 
08-025 is certainly possible, but it's a massive change to the way that 
PRs work today, and it throws up a bunch of nasty corner cases and 
backwards compatibility issues. 
The massive change comes from the fact that now the Target will have to 
remember which registrations are in the Reservation, and which are not. It 
will probably have to preserve all of the transport information for the 
life of the reservation. 
The corner cases are things like, what happens if there's no longer a 
registration that corresponds to the transport ID in the Reserve? Does the 
Reserve succeed? What happens if a registration comes in later, after the 
reservation has been established - does that device it get access? 
Backwards compatibility issues may arise like this: An existing device 
registers, and finds it has no access, so it does a PR In and finds out 
that a reservation is in place, retries its access and still it has no 
access. What does it do next, preempt the reservation because it assumes 
the Target is broken? 
Reserve also has to be an "atomic" command, and I've always thought that 
was why it's functionality is as compact as it is today. Most of the 
complex operations related to addresses and keys are done at registration 
time, and those operations don't have to be atomic. 
One more thing: you chose for your new "group" reservations to follow the 
"all registrants" approach is terms of the definition of the reservation 
holder. While that's fine by me (obviously), I suspect there are also 
situations where group reservations that follow the "registrants only" 
approach might be useful. 
The bottom line from my point of view is this: Your proposal is feasible 
and we can probably make it work. But I wonder if there's an easier way to 
achieve the same goal that is more compatible with existing practice and 
requires less of a change in functionality on the Target side. 
What if we didn't add any new reservations types, but instead added some 
new functionality to the registration process? What I'm thinking of a new 
Register feature that causes the Target to kill all existing 
registrations, create the registrations identified in the transport IDs in 
the Register command, and not accept any future registrations. That way, 
we don't need any changes to Reserve, and an Initiator with existing 
functionality would just not be able to register and therefore would not 
be confused. 
Does that make sense to you? Is there a chance this is an easier approach? 
If so, I'll write up a detailed proposal that's the equivalent of 08-025r0 
and we can compare and contrast at the next CAP. 
Again, thanks for getting this started, I think it's a worthwhile endeavor 
and I'll be glad to put some cycles towards defining this sort of 
functionality for SPC-4. 
Regards, 
Roger 
From: owner-t10 at t10.org [mailto:owner-t10 at t10.org] On Behalf Of Kevin D 
Butt
Sent: Monday, December 10, 2007 4:18 PM
To: t10 at t10.org
Subject: Persistent Reservation Proposal - Group Reservations
I have posted two documents related to an additional Persistent 
Reservation Type.  The first document is a presentation on where 
persistent reservations are today and where they fall short in the 
scenarios covered by the proposal.  It also covers the intent of the 
proposal and what will be proposed.  The second is the actual proposal 
Your PDF file will be posted at:
 http://www.t10.org/ftp/t10/document.08/08-024r0.pdf 
  http://www.t10.org/ftp/t10/document.08/08-025r0.pdf
Normally, the posting/archiving process takes about 30 minutes. 
Kevin D. Butt
SCSI & Fibre Channel Architect, Tape Firmware, IBM
MS 6TYA, 9000 S. Rita Rd., Tucson, AZ 85744
Tel: 520-799-2869 / 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 gop at us.ibm.com  Mon Dec 17 14:36:09 2007
From: gop at us.ibm.com (George Penokie)
Date: Mon, 17 Dec 2007 16:36:09 -0600
Subject: Reminder: T10 Security Conference calls schedule for Dec 18th
Message-ID: <mailman.836.1441607323.22512.t10@sandbox.t10.org>

Formatted message: <A HREF="r0712173_f.htm">HTML-formatted message</A>

Here is the proposed agenda for the 12/18 T10 security conference call: 
7.  Security
7.1   Capability based Command Security (07-454r3) [Penokie]
7.2   ESP-SCSI for Parameter Data (07-169r4) [Weber
Date: 12/18/2007 
Time: 10:00 am - 12:00 central time 
Audio Conference Access Numbers
USA: 770-615-1254 (Note: this number may be a problem in some locations), 
Tie-Line 421-0038 or 1-877-421-0038
Passcode: 198458 
Topic: T10 Security Meeting 
Date: Tuesday, December 18, 2007 
Time: 10:00 am, Central Standard Time (GMT -06:00, Chicago ) 
Meeting Number: 571 468 084 
Meeting Password: secure 
Please click the link below to see more information, or to join the 
meeting. 
------------------------------------------------------- 
To join the online meeting 
------------------------------------------------------- 
1. Go to https://lsilogic.webex.com/lsilogic/j.php?ED=101542287&UID=0 
2. Enter your name and email address. 
3. Enter the meeting password: secure 
4. Click "Join". 
Bye for now,
George Penokie
Dept 9A8 030-3 A410
E-Mail:    gop at us.ibm.com
Internal:  553-5208


From ai.takaharu at jp.panasonic.com  Tue Dec 18 02:24:23 2007
From: ai.takaharu at jp.panasonic.com (Takaharu Ai)
Date: Tue, 18 Dec 2007 19:24:23 +0900
Subject: December meeting
Message-ID: <mailman.837.1441607323.22512.t10@sandbox.t10.org>

* From the T10 Reflector (t10 at t10.org), posted by:
* Takaharu Ai <ai.takaharu at jp.panasonic.com>
*
Hello Mt.Fuji people,
December meeting has adjourned on Tuesday. We will not have the second
day meeting on Wednesday.
Draft meeting minutes will be posted soon.
Best Regards,
Harry Ai
VEBU
Panasonic AVC Networks Company
Matsushita/Panasonic
Osaka, Japan
*
* For T10 Reflector information, send a message with
* 'info t10' (no quotes) in the message body to majordomo at t10.org


From roger_cummings at symantec.com  Tue Dec 18 06:08:50 2007
From: roger_cummings at symantec.com (Roger Cummings)
Date: Tue, 18 Dec 2007 07:08:50 -0700
Subject: Persistent Reservation Proposal - Group Reservations
Message-ID: <mailman.838.1441607323.22512.t10@sandbox.t10.org>

Formatted message: <A HREF="r0712181_f.htm">HTML-formatted message</A>

Kevin,
Thanks for your comments in turn. 
I think we actually agree about a lot more in relation to this subject
than we disagree about, so we should be able to work through these
issues and come up with a single proposal that works for both of us - I
certainly don't want two different ways of doing this! But by the same
token I don't want a disk-type group reservation and a tape-type group
reservation either, and that means whatever we come up with has to be
straightforwardly implementable by devices that support the RO & AR PR
types today. 
And this is probably the major concern that I have with your proposal -
I believe it requires a Target to remember which registrations should be
included in the group for a Reservation, and to validate those
registrations within the context of an atomic Reserve operation. Whereas
my proposal prevents devices that are not in the group from registering
in the first place, and thus Reservations work just as they do today -
both the RO and AR types.
That having been said, I do not work for a hardware Target supplier that
supports PR today, so I might not be representing their concerns
adequately. Would anyone else more qualified care to comment on this
point?
With regards to the other points you raised:
a) I'm not sure we can rely on existing devices to check the type of an
existing reservation before registering. Those existing devices may
assume that they get access under ANY non-exclusive PR when they
register.
b) The point that you raise about registrations being denied is right,
but resource issues do happen and I know we do see that and handle that
in some of our code. On the other hand, a host that sees the
Registration being rejected, assumes that PR therefore isn't supported,
and falls back to RESERVE/RELEASE wouldn't be very good! I think we
always now use PR IN to check for PR support, but I'll check that.
c) Yes, I agree that the RO & AR types aren't very interesting or
significant in the tape world, but they are interesting in other uses
and some of those uses could really use the other features of your
proposal.
d) Re the corner cases, let me ask this question? If a device that has
access under the reservation de-registers, and then registers again,
does it have access? If we can hold the line of definitely not, then I
agree that will be simpler, but I'm not sure that's feasible.
e) I agree about the need for a new ASCQ, and yes there would be pain on
the host side at the register point. But the host has to handle that
action in the resource conflict case today, and handling it there saves
the target a whole lot of work.
f) I don't have an issue with reporting Reservation Conflict when one of
the new Reservations are in place, but you'd only do that under the
existing conflict rules, right? You'd still allow registrations to be
accepted after the Reservation was in place, just that those new
registrations would get access - that what I'm worried about.
And BTW we still have another major issue to discuss. Do you want to
change anything regarding Preempt?
Regards,
Roger
________________________________
	From: Kevin D Butt [mailto:kdbutt at us.ibm.com] 
	Sent: Monday, December 17, 2007 9:51 AM
	To: Roger Cummings
	Cc: t10 at t10.org
	Subject: RE: Persistent Reservation Proposal - Group
Reservations
	Roger, 
	Thank you for your feedback.  I am certainly willing to
entertain  other methods for accomplishing the end goal in an easier
fashion.  I am not sure I understand how your proposed method makes it
more backward compatible.  In my proposal PRin would show a different
type of reservation and hence the application clients would not try to
join the reservation because they don't know about the type.  In your
proposal, application clients would not be allowed to register.  This is
a deviation from what they can always do today - unless there is a
resource issue.  This seems more disruptive to me.  I would assume that
there would be a new additional sense code added for UNABLE TO REGISTER
BECAUSE A GROUP RESERVATION IS IN PLACE (or analogous).  This would be a
new thing for failure to register and there would be pain at the
register point.  Perhaps that is better than at the reserve point - but
I would think that it would be better handled as a reservation conflict
since that is what it is instead of something the application client
does not understand. 
	As for "all registrants" type vs. "registrants only" I didn't
see where the difference would be interesting, but I am not opposed to
providing a way to switch between which of these two types is done.
Whether it is additional types or some bit during registration etc. 
	As for some of the corner cases mentioned below, if each I_T
nexus that is supposed to be part of the group reservation is required
to be registered before the reservation is made, and if the reservation
is released when the last group reservation participant is unregistered,
then I think we don't have an issue. 
	I would prefer that we work together to shape a mutually
beneficial proposal as opposed to have "competing" proposals.  I am
willing to modify my proposal where it can be made easier and such.  I
am not sold that my proposed method is the only way or even the best -
it's just the way I thought of doing it.  I admit that I have always
been very confused about the usefulness of RA and AR types.  They make
absolutely no sense in the tape world. 
	Thanks, 
	Kevin D. Butt
	SCSI & Fibre Channel Architect, Tape Firmware
	MS 6TYA, 9000 S. Rita Rd., Tucson, AZ 85744
	Tel: 520-799-2869 / 520-799-5280
	Fax: 520-799-2723 (T/L:321)
	Email address: kdbutt at us.ibm.com
	http://www-03.ibm.com/servers/storage/ 
"Roger Cummings" <roger_cummings at symantec.com> 
Sent by: owner-t10 at t10.org 
12/14/2007 12:10 PM 
To
Kevin D Butt/Tucson/IBM at IBMUS 
cc
<t10 at t10.org> 
Subject
RE: Persistent Reservation Proposal - Group Reservations	
	Kevin, 
	First of all, let me say that I completely support what you're
trying to do here. I think that providing a method in persistent
reservations (PRs) to support shared access between ONLY a
specifically-designated set of systems is a worthy goal, and something
we should do in SPC-4. 
	Adding a set of Transport IDs to Reserve as per your document
08-024 & 08-025 is certainly possible, but it's a massive change to the
way that PRs work today, and it throws up a bunch of nasty corner cases
and backwards compatibility issues. 
	The massive change comes from the fact that now the Target will
have to remember which registrations are in the Reservation, and which
are not. It will probably have to preserve all of the transport
information for the life of the reservation. 
	The corner cases are things like, what happens if there's no
longer a registration that corresponds to the transport ID in the
Reserve? Does the Reserve succeed? What happens if a registration comes
in later, after the reservation has been established - does that device
it get access? 
	Backwards compatibility issues may arise like this: An existing
device registers, and finds it has no access, so it does a PR In and
finds out that a reservation is in place, retries its access and still
it has no access. What does it do next, preempt the reservation because
it assumes the Target is broken? 
	Reserve also has to be an "atomic" command, and I've always
thought that was why it's functionality is as compact as it is today.
Most of the complex operations related to addresses and keys are done at
registration time, and those operations don't have to be atomic. 
	One more thing: you chose for your new "group" reservations to
follow the "all registrants" approach is terms of the definition of the
reservation holder. While that's fine by me (obviously), I suspect there
are also situations where group reservations that follow the
"registrants only" approach might be useful. 
	The bottom line from my point of view is this: Your proposal is
feasible and we can probably make it work. But I wonder if there's an
easier way to achieve the same goal that is more compatible with
existing practice and requires less of a change in functionality on the
Target side. 
	What if we didn't add any new reservations types, but instead
added some new functionality to the registration process? What I'm
thinking of a new Register feature that causes the Target to kill all
existing registrations, create the registrations identified in the
transport IDs in the Register command, and not accept any future
registrations. That way, we don't need any changes to Reserve, and an
Initiator with existing functionality would just not be able to register
and therefore would not be confused. 
	Does that make sense to you? Is there a chance this is an easier
approach? If so, I'll write up a detailed proposal that's the equivalent
of 08-025r0 and we can compare and contrast at the next CAP. 
	Again, thanks for getting this started, I think it's a
worthwhile endeavor and I'll be glad to put some cycles towards defining
this sort of functionality for SPC-4. 
	Regards, 
	Roger 
________________________________
	From: owner-t10 at t10.org [mailto:owner-t10 at t10.org] On Behalf Of
Kevin D Butt
	Sent: Monday, December 10, 2007 4:18 PM
	To: t10 at t10.org
	Subject: Persistent Reservation Proposal - Group Reservations
	I have posted two documents related to an additional Persistent
Reservation Type.  The first document is a presentation on where
persistent reservations are today and where they fall short in the
scenarios covered by the proposal.  It also covers the intent of the
proposal and what will be proposed.  The second is the actual proposal 
	Your PDF file will be posted at:
	 http://www.t10.org/ftp/t10/document.08/08-024r0.pdf 
	  http://www.t10.org/ftp/t10/document.08/08-025r0.pdf
	Normally, the posting/archiving process takes about 30 minutes. 
	Kevin D. Butt
	SCSI & Fibre Channel Architect, Tape Firmware, IBM
	MS 6TYA, 9000 S. Rita Rd., Tucson, AZ 85744
	Tel: 520-799-2869 / 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 roger_cummings at symantec.com  Tue Dec 18 07:03:02 2007
From: roger_cummings at symantec.com (Roger Cummings)
Date: Tue, 18 Dec 2007 08:03:02 -0700
Subject: Persistent Reservation Proposal - Group Reservations
Message-ID: <mailman.839.1441607323.22512.t10@sandbox.t10.org>

Formatted message: <A HREF="r0712182_f.htm">HTML-formatted message</A>

Kevin,
I'm sorry, I don't think it's as cut and dried as you make out. This
gets into some of the corner cases that I listed in my first response.
The point to be made in response to Fred's case is that a third-party
can create registrations for a downed initiator (via the SPEC_I_PT) bit,
so that when it comes up again it will be able to participate in the
reservation without having to register itself.
Also, you say that "We have made provisions for adding members once the
reservation exists, but only one of the reservation holders can add
another entity." Two things in response to that:
1) I didn't see any specific provision for adding members in your
proposal, so I presume you'd just issue another RESERVE with the same
type and the whole list of transport IDs to be included again, and thus
the Target would have a whole lot of work to do again to set up another
reservation.
2) I that really what you want, that an member of the existing group can
reissue the RESERVE with a whole bunch of different TransportIDs,
perhaps excluding some that were previously there?
Regards,
Roger
________________________________
From: owner-t10 at t10.org [mailto:owner-t10 at t10.org] On Behalf Of Kevin D
Butt
Sent: Monday, December 17, 2007 3:54 PM
To: Knight, Frederick
Cc: t10 at t10.org; Christine R Knibloe
Subject: RE: Persistent Reservation Proposal - Group Reservations
	Fred, 
	This is being proposed for SPC. 
	There are multiple types of reservations.  In an environment
where one node of a cluster must join later, one of the other types can
be used.  Either that or have an existing node in your cluster add the
new node.  The whole intent of this Group reservation is to lock out
everybody that is not explicitly specified during the reserve.	We have
made provisions for adding members once the reservation exists, but only
one of the reservation holders can add another entity.	The new entity
cannot add itself.  This is the whole point of reservations (i.e., lock
out others from doing stuff while I think I have exclusive rights). 
	To put it in other word's, to allow somebody to join the
reservation of their own accord without permission is EXACTLY what I am
trying to protect against. 
	Thanks, 
	Kevin D. Butt
	SCSI & Fibre Channel Architect, Tape Firmware
	MS 6TYA, 9000 S. Rita Rd., Tucson, AZ 85744
	Tel: 520-799-2869 / 520-799-5280
	Fax: 520-799-2723 (T/L:321)
	Email address: kdbutt at us.ibm.com
	http://www-03.ibm.com/servers/storage/ 
"Knight, Frederick" <Frederick.Knight at netapp.com> 
12/17/2007 01:38 PM 
To
Kevin D Butt/Tucson/IBM at IBMUS 
cc
Subject
RE: Persistent Reservation Proposal - Group Reservations
	Sorry, you can't require everyone to register before the
reserve. 
	That's like saying my whole cluster can't boot because 1 node is
down.  You need 
	to have a way for a "down" initiator to join the fun after the
fact. 
	I helped write a host cluster product that used a shared tape
(failover model).  The 
	backup application would write to the tape.  If a system failure
ever happened, the 
	backup application would failover to a different host.	It would
skip backwards on 
	the tape for a few records, recognize where it left off, and
then resume operation. 
	BUT, for some protection, we used reservations to make sure only
1 initiator at a 
	time could access the tape.  The interesting point however, is
that we were in the 
	process of upgrading from old SCSI-2 RESERVE to using PR.
Because, we also 
	have multiple HBAs in the host, and we wanted to be able to use
more than 1 of 
	those HBAs (so we needed multiple reservations - aka PR).
Having this idea 
	(group reservations) would have been a real nice addition. 
	As for the RA/AR differences.  It seemed to be timing.
Registrants Only was fairly 
	early on (as I remember), and so implemented by several O/S
vendors.  Later on, 
	some issues were found (which got complicated spec-ees added to
address), but also, 
	the All Registrants was added (which didn't have those issues).
But, since there were 
	implementations, it couldn't be removed like the other old PR
types that no one ever 
	used.  Anyway, I agree, they offer basically the same
capabilities, but RO is already 
	out there, and AR is probably what new implementers are using
(it's easier to understand 
	and implement from the host side).  Most of the differences are
already documented, 
	so there wouldn't be that much extra for you to write to have
both types (which I think 
	would be better than bit somewhere - do it the same way all the
others are done).  But, 
	you could also just do the AR version, and let someone else add
the RO version if they 
	want it. 
	Are you proposing this for tape only? or SPC in general?  I
assume SPC in general. 
	    Fred Knight 
________________________________
	From: Kevin D Butt [mailto:kdbutt at us.ibm.com] 
	Sent: Monday, December 17, 2007 9:51 AM
	To: Roger Cummings
	Cc: t10 at t10.org
	Subject: RE: Persistent Reservation Proposal - Group
Reservations
	Roger, 
	Thank you for your feedback.  I am certainly willing to
entertain  other methods for accomplishing the end goal in an easier
fashion.  I am not sure I understand how your proposed method makes it
more backward compatible.  In my proposal PRin would show a different
type of reservation and hence the application clients would not try to
join the reservation because they don't know about the type.  In your
proposal, application clients would not be allowed to register.  This is
a deviation from what they can always do today - unless there is a
resource issue.  This seems more disruptive to me.  I would assume that
there would be a new additional sense code added for UNABLE TO REGISTER
BECAUSE A GROUP RESERVATION IS IN PLACE (or analogous).  This would be a
new thing for failure to register and there would be pain at the
register point.  Perhaps that is better than at the reserve point - but
I would think that it would be better handled as a reservation conflict
since that is what it is instead of something the application client
does not understand. 
	As for "all registrants" type vs. "registrants only" I didn't
see where the difference would be interesting, but I am not opposed to
providing a way to switch between which of these two types is done.
Whether it is additional types or some bit during registration etc. 
	As for some of the corner cases mentioned below, if each I_T
nexus that is supposed to be part of the group reservation is required
to be registered before the reservation is made, and if the reservation
is released when the last group reservation participant is unregistered,
then I think we don't have an issue. 
	I would prefer that we work together to shape a mutually
beneficial proposal as opposed to have "competing" proposals.  I am
willing to modify my proposal where it can be made easier and such.  I
am not sold that my proposed method is the only way or even the best -
it's just the way I thought of doing it.  I admit that I have always
been very confused about the usefulness of RA and AR types.  They make
absolutely no sense in the tape world. 
	Thanks, 
	Kevin D. Butt
	SCSI & Fibre Channel Architect, Tape Firmware
	MS 6TYA, 9000 S. Rita Rd., Tucson, AZ 85744
	Tel: 520-799-2869 / 520-799-5280
	Fax: 520-799-2723 (T/L:321)
	Email address: kdbutt at us.ibm.com
	http://www-03.ibm.com/servers/storage/ 
"Roger Cummings" <roger_cummings at symantec.com> 
Sent by: owner-t10 at t10.org 
12/14/2007 12:10 PM 
To
Kevin D Butt/Tucson/IBM at IBMUS 
cc
<t10 at t10.org> 
Subject
RE: Persistent Reservation Proposal - Group Reservations
	Kevin, 
	First of all, let me say that I completely support what you're
trying to do here. I think that providing a method in persistent
reservations (PRs) to support shared access between ONLY a
specifically-designated set of systems is a worthy goal, and something
we should do in SPC-4. 
	Adding a set of Transport IDs to Reserve as per your document
08-024 & 08-025 is certainly possible, but it's a massive change to the
way that PRs work today, and it throws up a bunch of nasty corner cases
and backwards compatibility issues. 
	The massive change comes from the fact that now the Target will
have to remember which registrations are in the Reservation, and which
are not. It will probably have to preserve all of the transport
information for the life of the reservation. 
	The corner cases are things like, what happens if there's no
longer a registration that corresponds to the transport ID in the
Reserve? Does the Reserve succeed? What happens if a registration comes
in later, after the reservation has been established - does that device
it get access? 
	Backwards compatibility issues may arise like this: An existing
device registers, and finds it has no access, so it does a PR In and
finds out that a reservation is in place, retries its access and still
it has no access. What does it do next, preempt the reservation because
it assumes the Target is broken? 
	Reserve also has to be an "atomic" command, and I've always
thought that was why it's functionality is as compact as it is today.
Most of the complex operations related to addresses and keys are done at
registration time, and those operations don't have to be atomic. 
	One more thing: you chose for your new "group" reservations to
follow the "all registrants" approach is terms of the definition of the
reservation holder. While that's fine by me (obviously), I suspect there
are also situations where group reservations that follow the
"registrants only" approach might be useful. 
	The bottom line from my point of view is this: Your proposal is
feasible and we can probably make it work. But I wonder if there's an
easier way to achieve the same goal that is more compatible with
existing practice and requires less of a change in functionality on the
Target side. 
	What if we didn't add any new reservations types, but instead
added some new functionality to the registration process? What I'm
thinking of a new Register feature that causes the Target to kill all
existing registrations, create the registrations identified in the
transport IDs in the Register command, and not accept any future
registrations. That way, we don't need any changes to Reserve, and an
Initiator with existing functionality would just not be able to register
and therefore would not be confused. 
	Does that make sense to you? Is there a chance this is an easier
approach? If so, I'll write up a detailed proposal that's the equivalent
of 08-025r0 and we can compare and contrast at the next CAP. 
	Again, thanks for getting this started, I think it's a
worthwhile endeavor and I'll be glad to put some cycles towards defining
this sort of functionality for SPC-4. 
	Regards, 
	Roger 
________________________________
	From: owner-t10 at t10.org [mailto:owner-t10 at t10.org] On Behalf Of
Kevin D Butt
	Sent: Monday, December 10, 2007 4:18 PM
	To: t10 at t10.org
	Subject: Persistent Reservation Proposal - Group Reservations
	I have posted two documents related to an additional Persistent
Reservation Type.  The first document is a presentation on where
persistent reservations are today and where they fall short in the
scenarios covered by the proposal.  It also covers the intent of the
proposal and what will be proposed.  The second is the actual proposal 
	Your PDF file will be posted at:
	http://www.t10.org/ftp/t10/document.08/08-024r0.pdf 
	 http://www.t10.org/ftp/t10/document.08/08-025r0.pdf
	Normally, the posting/archiving process takes about 30 minutes. 
	Kevin D. Butt
	SCSI & Fibre Channel Architect, Tape Firmware, IBM
	MS 6TYA, 9000 S. Rita Rd., Tucson, AZ 85744
	Tel: 520-799-2869 / 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 Frederick.Knight at netapp.com  Tue Dec 18 07:55:58 2007
From: Frederick.Knight at netapp.com (Knight, Frederick)
Date: Tue, 18 Dec 2007 10:55:58 -0500
Subject: Persistent Reservation Proposal - Group Reservations
Message-ID: <mailman.840.1441607324.22512.t10@sandbox.t10.org>

Formatted message: <A HREF="r0712183_f.htm">HTML-formatted message</A>

My question has had to do with differentiating the disaster clean up
case from the non-cooperating host case.
How do I clean up from a disaster?  If all my "reserved" initiators
melt down, and there aren't any of them left anymore (because of
a site disaster, or whatever), how does some other node come along
and clean up so it can gain access?
Would it require manual intervention?  Or, is there a way in the
protocol
that I can register and preempt the group reservation (does the use
of the SPEC_I_PT bit allow this as you have suggested Roger).  I
thought the SPEC_I_PT had to come from an already registered
initiator (which in a disaster, none exist anymore).
    Fred Knight
________________________________
From: Roger Cummings [mailto:roger_cummings at symantec.com] 
Sent: Tuesday, December 18, 2007 10:03 AM
To: Kevin D Butt; Knight, Frederick
Cc: t10 at t10.org; Christine R Knibloe
Subject: RE: Persistent Reservation Proposal - Group Reservations
Kevin,
I'm sorry, I don't think it's as cut and dried as you make out. This
gets into some of the corner cases that I listed in my first response.
The point to be made in response to Fred's case is that a third-party
can create registrations for a downed initiator (via the SPEC_I_PT) bit,
so that when it comes up again it will be able to participate in the
reservation without having to register itself.
Also, you say that "We have made provisions for adding members once the
reservation exists, but only one of the reservation holders can add
another entity." Two things in response to that:
1) I didn't see any specific provision for adding members in your
proposal, so I presume you'd just issue another RESERVE with the same
type and the whole list of transport IDs to be included again, and thus
the Target would have a whole lot of work to do again to set up another
reservation.
2) I that really what you want, that an member of the existing group can
reissue the RESERVE with a whole bunch of different TransportIDs,
perhaps excluding some that were previously there?
Regards,
Roger
________________________________
From: owner-t10 at t10.org [mailto:owner-t10 at t10.org] On Behalf Of Kevin D
Butt
Sent: Monday, December 17, 2007 3:54 PM
To: Knight, Frederick
Cc: t10 at t10.org; Christine R Knibloe
Subject: RE: Persistent Reservation Proposal - Group Reservations
	Fred, 
	This is being proposed for SPC. 
	There are multiple types of reservations.  In an environment
where one node of a cluster must join later, one of the other types can
be used.  Either that or have an existing node in your cluster add the
new node.  The whole intent of this Group reservation is to lock out
everybody that is not explicitly specified during the reserve.	We have
made provisions for adding members once the reservation exists, but only
one of the reservation holders can add another entity.	The new entity
cannot add itself.  This is the whole point of reservations (i.e., lock
out others from doing stuff while I think I have exclusive rights). 
	To put it in other word's, to allow somebody to join the
reservation of their own accord without permission is EXACTLY what I am
trying to protect against. 
	Thanks, 
	Kevin D. Butt
	SCSI & Fibre Channel Architect, Tape Firmware
	MS 6TYA, 9000 S. Rita Rd., Tucson, AZ 85744
	Tel: 520-799-2869 / 520-799-5280
	Fax: 520-799-2723 (T/L:321)
	Email address: kdbutt at us.ibm.com
	http://www-03.ibm.com/servers/storage/ 
"Knight, Frederick" <Frederick.Knight at netapp.com> 
12/17/2007 01:38 PM 
To
Kevin D Butt/Tucson/IBM at IBMUS 
cc
Subject
RE: Persistent Reservation Proposal - Group Reservations	
	Sorry, you can't require everyone to register before the
reserve. 
	That's like saying my whole cluster can't boot because 1 node is
down.  You need 
	to have a way for a "down" initiator to join the fun after the
fact. 
	I helped write a host cluster product that used a shared tape
(failover model).  The 
	backup application would write to the tape.  If a system failure
ever happened, the 
	backup application would failover to a different host.	It would
skip backwards on 
	the tape for a few records, recognize where it left off, and
then resume operation. 
	BUT, for some protection, we used reservations to make sure only
1 initiator at a 
	time could access the tape.  The interesting point however, is
that we were in the 
	process of upgrading from old SCSI-2 RESERVE to using PR.
Because, we also 
	have multiple HBAs in the host, and we wanted to be able to use
more than 1 of 
	those HBAs (so we needed multiple reservations - aka PR).
Having this idea 
	(group reservations) would have been a real nice addition. 
	As for the RA/AR differences.  It seemed to be timing.
Registrants Only was fairly 
	early on (as I remember), and so implemented by several O/S
vendors.  Later on, 
	some issues were found (which got complicated spec-ees added to
address), but also, 
	the All Registrants was added (which didn't have those issues).
But, since there were 
	implementations, it couldn't be removed like the other old PR
types that no one ever 
	used.  Anyway, I agree, they offer basically the same
capabilities, but RO is already 
	out there, and AR is probably what new implementers are using
(it's easier to understand 
	and implement from the host side).  Most of the differences are
already documented, 
	so there wouldn't be that much extra for you to write to have
both types (which I think 
	would be better than bit somewhere - do it the same way all the
others are done).  But, 
	you could also just do the AR version, and let someone else add
the RO version if they 
	want it. 
	Are you proposing this for tape only? or SPC in general?  I
assume SPC in general. 
	    Fred Knight 
________________________________
	From: Kevin D Butt [mailto:kdbutt at us.ibm.com] 
	Sent: Monday, December 17, 2007 9:51 AM
	To: Roger Cummings
	Cc: t10 at t10.org
	Subject: RE: Persistent Reservation Proposal - Group
Reservations
	Roger, 
	Thank you for your feedback.  I am certainly willing to
entertain  other methods for accomplishing the end goal in an easier
fashion.  I am not sure I understand how your proposed method makes it
more backward compatible.  In my proposal PRin would show a different
type of reservation and hence the application clients would not try to
join the reservation because they don't know about the type.  In your
proposal, application clients would not be allowed to register.  This is
a deviation from what they can always do today - unless there is a
resource issue.  This seems more disruptive to me.  I would assume that
there would be a new additional sense code added for UNABLE TO REGISTER
BECAUSE A GROUP RESERVATION IS IN PLACE (or analogous).  This would be a
new thing for failure to register and there would be pain at the
register point.  Perhaps that is better than at the reserve point - but
I would think that it would be better handled as a reservation conflict
since that is what it is instead of something the application client
does not understand. 
	As for "all registrants" type vs. "registrants only" I didn't
see where the difference would be interesting, but I am not opposed to
providing a way to switch between which of these two types is done.
Whether it is additional types or some bit during registration etc. 
	As for some of the corner cases mentioned below, if each I_T
nexus that is supposed to be part of the group reservation is required
to be registered before the reservation is made, and if the reservation
is released when the last group reservation participant is unregistered,
then I think we don't have an issue. 
	I would prefer that we work together to shape a mutually
beneficial proposal as opposed to have "competing" proposals.  I am
willing to modify my proposal where it can be made easier and such.  I
am not sold that my proposed method is the only way or even the best -
it's just the way I thought of doing it.  I admit that I have always
been very confused about the usefulness of RA and AR types.  They make
absolutely no sense in the tape world. 
	Thanks, 
	Kevin D. Butt
	SCSI & Fibre Channel Architect, Tape Firmware
	MS 6TYA, 9000 S. Rita Rd., Tucson, AZ 85744
	Tel: 520-799-2869 / 520-799-5280
	Fax: 520-799-2723 (T/L:321)
	Email address: kdbutt at us.ibm.com
	http://www-03.ibm.com/servers/storage/ 
"Roger Cummings" <roger_cummings at symantec.com> 
Sent by: owner-t10 at t10.org 
12/14/2007 12:10 PM 
To
Kevin D Butt/Tucson/IBM at IBMUS 
cc
<t10 at t10.org> 
Subject
RE: Persistent Reservation Proposal - Group Reservations	
	Kevin, 
	First of all, let me say that I completely support what you're
trying to do here. I think that providing a method in persistent
reservations (PRs) to support shared access between ONLY a
specifically-designated set of systems is a worthy goal, and something
we should do in SPC-4. 
	Adding a set of Transport IDs to Reserve as per your document
08-024 & 08-025 is certainly possible, but it's a massive change to the
way that PRs work today, and it throws up a bunch of nasty corner cases
and backwards compatibility issues. 
	The massive change comes from the fact that now the Target will
have to remember which registrations are in the Reservation, and which
are not. It will probably have to preserve all of the transport
information for the life of the reservation. 
	The corner cases are things like, what happens if there's no
longer a registration that corresponds to the transport ID in the
Reserve? Does the Reserve succeed? What happens if a registration comes
in later, after the reservation has been established - does that device
it get access? 
	Backwards compatibility issues may arise like this: An existing
device registers, and finds it has no access, so it does a PR In and
finds out that a reservation is in place, retries its access and still
it has no access. What does it do next, preempt the reservation because
it assumes the Target is broken? 
	Reserve also has to be an "atomic" command, and I've always
thought that was why it's functionality is as compact as it is today.
Most of the complex operations related to addresses and keys are done at
registration time, and those operations don't have to be atomic. 
	One more thing: you chose for your new "group" reservations to
follow the "all registrants" approach is terms of the definition of the
reservation holder. While that's fine by me (obviously), I suspect there
are also situations where group reservations that follow the
"registrants only" approach might be useful. 
	The bottom line from my point of view is this: Your proposal is
feasible and we can probably make it work. But I wonder if there's an
easier way to achieve the same goal that is more compatible with
existing practice and requires less of a change in functionality on the
Target side. 
	What if we didn't add any new reservations types, but instead
added some new functionality to the registration process? What I'm
thinking of a new Register feature that causes the Target to kill all
existing registrations, create the registrations identified in the
transport IDs in the Register command, and not accept any future
registrations. That way, we don't need any changes to Reserve, and an
Initiator with existing functionality would just not be able to register
and therefore would not be confused. 
	Does that make sense to you? Is there a chance this is an easier
approach? If so, I'll write up a detailed proposal that's the equivalent
of 08-025r0 and we can compare and contrast at the next CAP. 
	Again, thanks for getting this started, I think it's a
worthwhile endeavor and I'll be glad to put some cycles towards defining
this sort of functionality for SPC-4. 
	Regards, 
	Roger 
________________________________
	From: owner-t10 at t10.org [mailto:owner-t10 at t10.org] On Behalf Of
Kevin D Butt
	Sent: Monday, December 10, 2007 4:18 PM
	To: t10 at t10.org
	Subject: Persistent Reservation Proposal - Group Reservations
	I have posted two documents related to an additional Persistent
Reservation Type.  The first document is a presentation on where
persistent reservations are today and where they fall short in the
scenarios covered by the proposal.  It also covers the intent of the
proposal and what will be proposed.  The second is the actual proposal 
	Your PDF file will be posted at:
	http://www.t10.org/ftp/t10/document.08/08-024r0.pdf 
	 http://www.t10.org/ftp/t10/document.08/08-025r0.pdf
	Normally, the posting/archiving process takes about 30 minutes. 
	Kevin D. Butt
	SCSI & Fibre Channel Architect, Tape Firmware, IBM
	MS 6TYA, 9000 S. Rita Rd., Tucson, AZ 85744
	Tel: 520-799-2869 / 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 roger_cummings at symantec.com  Tue Dec 18 08:24:17 2007
From: roger_cummings at symantec.com (Roger Cummings)
Date: Tue, 18 Dec 2007 09:24:17 -0700
Subject: Persistent Reservation Proposal - Group Reservations
Message-ID: <mailman.841.1441607324.22512.t10@sandbox.t10.org>

Formatted message: <A HREF="r0712184_f.htm">HTML-formatted message</A>

Fred,
The way you clean up from a disaster is to Preempt, that's what it's
there for. Most of the applications that I know that will actually issue
a Preempt make it a very special function that doesn't happen in the
normal flow, and one app at least DOES require manual intervention of an
operator before kicking off the preempt.
Yes, today, a Preempt has to be issued through a registered I_T nexus,
but a registration with the SPEC_I_T bit doesn't have to come from an
already registered initiator - see Table 33 in SPC-4, and I don't
believe Kevin changed that in his proposal.
For the future, however we define a "group" for the purposes of new
reservation types, we will have to make sure that an Initiator outside
of the "group" can issue a Preempt to handle the disaster recovery case.
Regards,
Roger
________________________________
	From: Knight, Frederick [mailto:Frederick.Knight at netapp.com] 
	Sent: Tuesday, December 18, 2007 10:56 AM
	To: Roger Cummings; Kevin D Butt
	Cc: t10 at t10.org; Christine R Knibloe
	Subject: RE: Persistent Reservation Proposal - Group
Reservations
	My question has had to do with differentiating the disaster
clean up
	case from the non-cooperating host case.
	How do I clean up from a disaster?  If all my "reserved"
initiators
	melt down, and there aren't any of them left anymore (because of
	a site disaster, or whatever), how does some other node come
along
	and clean up so it can gain access?
	Would it require manual intervention?  Or, is there a way in the
protocol
	that I can register and preempt the group reservation (does the
use
	of the SPEC_I_PT bit allow this as you have suggested Roger).  I
	thought the SPEC_I_PT had to come from an already registered
	initiator (which in a disaster, none exist anymore).
	    Fred Knight
________________________________
	From: Roger Cummings [mailto:roger_cummings at symantec.com] 
	Sent: Tuesday, December 18, 2007 10:03 AM
	To: Kevin D Butt; Knight, Frederick
	Cc: t10 at t10.org; Christine R Knibloe
	Subject: RE: Persistent Reservation Proposal - Group
Reservations
	Kevin,
	I'm sorry, I don't think it's as cut and dried as you make out.
This gets into some of the corner cases that I listed in my first
response.
	The point to be made in response to Fred's case is that a
third-party can create registrations for a downed initiator (via the
SPEC_I_PT) bit, so that when it comes up again it will be able to
participate in the reservation without having to register itself.
	Also, you say that "We have made provisions for adding members
once the reservation exists, but only one of the reservation holders can
add another entity." Two things in response to that:
	1) I didn't see any specific provision for adding members in
your proposal, so I presume you'd just issue another RESERVE with the
same type and the whole list of transport IDs to be included again, and
thus the Target would have a whole lot of work to do again to set up
another reservation.
	2) I that really what you want, that an member of the existing
group can reissue the RESERVE with a whole bunch of different
TransportIDs, perhaps excluding some that were previously there?
	Regards,
	Roger
________________________________
	From: owner-t10 at t10.org [mailto:owner-t10 at t10.org] On Behalf Of
Kevin D Butt
	Sent: Monday, December 17, 2007 3:54 PM
	To: Knight, Frederick
	Cc: t10 at t10.org; Christine R Knibloe
	Subject: RE: Persistent Reservation Proposal - Group
Reservations
		Fred, 
		This is being proposed for SPC. 
		There are multiple types of reservations.  In an
environment where one node of a cluster must join later, one of the
other types can be used.  Either that or have an existing node in your
cluster add the new node.  The whole intent of this Group reservation is
to lock out everybody that is not explicitly specified during the
reserve.  We have made provisions for adding members once the
reservation exists, but only one of the reservation holders can add
another entity.  The new entity cannot add itself.  This is the whole
point of reservations (i.e., lock out others from doing stuff while I
think I have exclusive rights). 
		To put it in other word's, to allow somebody to join the
reservation of their own accord without permission is EXACTLY what I am
trying to protect against. 
		Thanks, 
		Kevin D. Butt
		SCSI & Fibre Channel Architect, Tape Firmware
		MS 6TYA, 9000 S. Rita Rd., Tucson, AZ 85744
		Tel: 520-799-2869 / 520-799-5280
		Fax: 520-799-2723 (T/L:321)
		Email address: kdbutt at us.ibm.com
		http://www-03.ibm.com/servers/storage/ 
"Knight, Frederick" <Frederick.Knight at netapp.com> 
12/17/2007 01:38 PM 
To
Kevin D Butt/Tucson/IBM at IBMUS 
cc
Subject
RE: Persistent Reservation Proposal - Group Reservations	
		Sorry, you can't require everyone to register before the
reserve. 
		That's like saying my whole cluster can't boot because 1
node is down.  You need 
		to have a way for a "down" initiator to join the fun
after the fact. 
		I helped write a host cluster product that used a shared
tape (failover model).	The 
		backup application would write to the tape.  If a system
failure ever happened, the 
		backup application would failover to a different host.
It would skip backwards on 
		the tape for a few records, recognize where it left off,
and then resume operation. 
		BUT, for some protection, we used reservations to make
sure only 1 initiator at a 
		time could access the tape.  The interesting point
however, is that we were in the 
		process of upgrading from old SCSI-2 RESERVE to using
PR.  Because, we also 
		have multiple HBAs in the host, and we wanted to be able
to use more than 1 of 
		those HBAs (so we needed multiple reservations - aka
PR).  Having this idea 
		(group reservations) would have been a real nice
addition. 
		As for the RA/AR differences.  It seemed to be timing.
Registrants Only was fairly 
		early on (as I remember), and so implemented by several
O/S vendors.  Later on, 
		some issues were found (which got complicated spec-ees
added to address), but also, 
		the All Registrants was added (which didn't have those
issues).  But, since there were 
		implementations, it couldn't be removed like the other
old PR types that no one ever 
		used.  Anyway, I agree, they offer basically the same
capabilities, but RO is already 
		out there, and AR is probably what new implementers are
using (it's easier to understand 
		and implement from the host side).  Most of the
differences are already documented, 
		so there wouldn't be that much extra for you to write to
have both types (which I think 
		would be better than bit somewhere - do it the same way
all the others are done).  But, 
		you could also just do the AR version, and let someone
else add the RO version if they 
		want it. 
		Are you proposing this for tape only? or SPC in general?
I assume SPC in general. 
		    Fred Knight 
________________________________
		From: Kevin D Butt [mailto:kdbutt at us.ibm.com] 
		Sent: Monday, December 17, 2007 9:51 AM
		To: Roger Cummings
		Cc: t10 at t10.org
		Subject: RE: Persistent Reservation Proposal - Group
Reservations
		Roger, 
		Thank you for your feedback.  I am certainly willing to
entertain  other methods for accomplishing the end goal in an easier
fashion.  I am not sure I understand how your proposed method makes it
more backward compatible.  In my proposal PRin would show a different
type of reservation and hence the application clients would not try to
join the reservation because they don't know about the type.  In your
proposal, application clients would not be allowed to register.  This is
a deviation from what they can always do today - unless there is a
resource issue.  This seems more disruptive to me.  I would assume that
there would be a new additional sense code added for UNABLE TO REGISTER
BECAUSE A GROUP RESERVATION IS IN PLACE (or analogous).  This would be a
new thing for failure to register and there would be pain at the
register point.  Perhaps that is better than at the reserve point - but
I would think that it would be better handled as a reservation conflict
since that is what it is instead of something the application client
does not understand. 
		As for "all registrants" type vs. "registrants only" I
didn't see where the difference would be interesting, but I am not
opposed to providing a way to switch between which of these two types is
done.  Whether it is additional types or some bit during registration
etc. 
		As for some of the corner cases mentioned below, if each
I_T nexus that is supposed to be part of the group reservation is
required to be registered before the reservation is made, and if the
reservation is released when the last group reservation participant is
unregistered, then I think we don't have an issue. 
		I would prefer that we work together to shape a mutually
beneficial proposal as opposed to have "competing" proposals.  I am
willing to modify my proposal where it can be made easier and such.  I
am not sold that my proposed method is the only way or even the best -
it's just the way I thought of doing it.  I admit that I have always
been very confused about the usefulness of RA and AR types.  They make
absolutely no sense in the tape world. 
		Thanks, 
		Kevin D. Butt
		SCSI & Fibre Channel Architect, Tape Firmware
		MS 6TYA, 9000 S. Rita Rd., Tucson, AZ 85744
		Tel: 520-799-2869 / 520-799-5280
		Fax: 520-799-2723 (T/L:321)
		Email address: kdbutt at us.ibm.com
		http://www-03.ibm.com/servers/storage/ 
"Roger Cummings" <roger_cummings at symantec.com> 
Sent by: owner-t10 at t10.org 
12/14/2007 12:10 PM 
To
Kevin D Butt/Tucson/IBM at IBMUS 
cc
<t10 at t10.org> 
Subject
RE: Persistent Reservation Proposal - Group Reservations	
		Kevin, 
		First of all, let me say that I completely support what
you're trying to do here. I think that providing a method in persistent
reservations (PRs) to support shared access between ONLY a
specifically-designated set of systems is a worthy goal, and something
we should do in SPC-4. 
		Adding a set of Transport IDs to Reserve as per your
document 08-024 & 08-025 is certainly possible, but it's a massive
change to the way that PRs work today, and it throws up a bunch of nasty
corner cases and backwards compatibility issues. 
		The massive change comes from the fact that now the
Target will have to remember which registrations are in the Reservation,
and which are not. It will probably have to preserve all of the
transport information for the life of the reservation. 
		The corner cases are things like, what happens if
there's no longer a registration that corresponds to the transport ID in
the Reserve? Does the Reserve succeed? What happens if a registration
comes in later, after the reservation has been established - does that
device it get access? 
		Backwards compatibility issues may arise like this: An
existing device registers, and finds it has no access, so it does a PR
In and finds out that a reservation is in place, retries its access and
still it has no access. What does it do next, preempt the reservation
because it assumes the Target is broken? 
		Reserve also has to be an "atomic" command, and I've
always thought that was why it's functionality is as compact as it is
today. Most of the complex operations related to addresses and keys are
done at registration time, and those operations don't have to be atomic.
		One more thing: you chose for your new "group"
reservations to follow the "all registrants" approach is terms of the
definition of the reservation holder. While that's fine by me
(obviously), I suspect there are also situations where group
reservations that follow the "registrants only" approach might be
useful. 
		The bottom line from my point of view is this: Your
proposal is feasible and we can probably make it work. But I wonder if
there's an easier way to achieve the same goal that is more compatible
with existing practice and requires less of a change in functionality on
the Target side. 
		What if we didn't add any new reservations types, but
instead added some new functionality to the registration process? What
I'm thinking of a new Register feature that causes the Target to kill
all existing registrations, create the registrations identified in the
transport IDs in the Register command, and not accept any future
registrations. That way, we don't need any changes to Reserve, and an
Initiator with existing functionality would just not be able to register
and therefore would not be confused. 
		Does that make sense to you? Is there a chance this is
an easier approach? If so, I'll write up a detailed proposal that's the
equivalent of 08-025r0 and we can compare and contrast at the next CAP. 
		Again, thanks for getting this started, I think it's a
worthwhile endeavor and I'll be glad to put some cycles towards defining
this sort of functionality for SPC-4. 
		Regards, 
		Roger 
________________________________
		From: owner-t10 at t10.org [mailto:owner-t10 at t10.org] On
Behalf Of Kevin D Butt
		Sent: Monday, December 10, 2007 4:18 PM
		To: t10 at t10.org
		Subject: Persistent Reservation Proposal - Group
Reservations
		I have posted two documents related to an additional
Persistent Reservation Type.  The first document is a presentation on
where persistent reservations are today and where they fall short in the
scenarios covered by the proposal.  It also covers the intent of the
proposal and what will be proposed.  The second is the actual proposal 
		Your PDF file will be posted at:
		http://www.t10.org/ftp/t10/document.08/08-024r0.pdf 
		 http://www.t10.org/ftp/t10/document.08/08-025r0.pdf
		Normally, the posting/archiving process takes about 30
minutes. 
		Kevin D. Butt
		SCSI & Fibre Channel Architect, Tape Firmware, IBM
		MS 6TYA, 9000 S. Rita Rd., Tucson, AZ 85744
		Tel: 520-799-2869 / 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 roweber at ieee.org  Tue Dec 18 10:16:51 2007
From: roweber at ieee.org (Ralph Weber)
Date: Tue, 18 Dec 2007 12:16:51 -0600
Subject: Updated ESP-SCSI proposal
Message-ID: <mailman.842.1441607324.22512.t10@sandbox.t10.org>

* From the T10 Reflector (t10 at t10.org), posted by:
* Ralph Weber <roweber at ieee.org>
*
A new revision of the ESP-SCSI proposal has been uploaded
to correct several byte-number errors in the data format
tables. This addresses the simpler of the issues raised
during this morning's conference call.
http://www.t10.org/ftp/t10/document.07/07-169r5.pdf
Those dependent on change bars for reviewing updates to
the proposal may prefer to continue using r4:
http://www.t10.org/ftp/t10/document.07/07-169r4.pdf
Another revision of 07-196 will be needed (after SPC-4
r12 is uploaded) to properly coordinate use of the
USAGE_DATA SA parameter between SA creation and ESP-SCSI.
All the best,
.Ralph
*
* For T10 Reflector information, send a message with
* 'info t10' (no quotes) in the message body to majordomo at t10.org


From gop at us.ibm.com  Tue Dec 18 13:02:31 2007
From: gop at us.ibm.com (George Penokie)
Date: Tue, 18 Dec 2007 15:02:31 -0600
Subject: Fw: 07-454r3 editorial comment
Message-ID: <mailman.843.1441607324.22512.t10@sandbox.t10.org>

Formatted message: <A HREF="r0712186_f.htm">HTML-formatted message</A>

Hi, George. 
In Table 26, I recommend changing "ACC ROBOT" to "ACC ROBOTICS."  The term 
robot does not appear in SMC-3, but robotics does.
Thanks, 
Paul Suhler


From GBarton at overlandstorage.com  Tue Dec 18 14:06:41 2007
From: GBarton at overlandstorage.com (GBarton at overlandstorage.com)
Date: Tue, 18 Dec 2007 14:06:41 -0800
Subject: ADI - SMC tape alerts using ADI bridging (re proposal 06-420r2 and
    smc3r09)
Message-ID: <mailman.844.1441607324.22512.t10@sandbox.t10.org>

Formatted message: <A HREF="r0712187_f.htm">HTML-formatted message</A>

In reviewing Michael Banther's proposal for tape alert flag (06-420r2), it 
occurred to me that there is a problem with SMC tape alerts in general if 
ADI bridging is being used for host access to the library. 
smc3r09 clause 5.2.2 third paragraph defines deactivations for tape 
alerts. Numbered list 1) states "after the TapeAlert log page is read. The 
TapeAlert flags shall be deactivated on a per-initiator basis such that 
active flags are available for other initiators; ". 
and in proposal 06-420r2 clause 5.4.4 last paragraph, the same statement 
is made with "should" instead of "shall".
Since a library device using ADI bridging is not aware of initiators, the 
library cannot clear the flags on a per initiator basis. Does this mean 
the DT device must cache the tape alert log page and keep track of the 
reads of that log page? If so, how does the DT device know when to cache a 
new page? And if the DT device handles the tape alert log page on a per 
initiator basis, how does the library know when to clear the flags? As far 
as I can tell, there is no mechanism to handle this.
Even if proposal 06-420r2 is not incorporated into smc3, the problem still 
exists.
regards,
Geoffrey L. Barton
Overland Storage
----------------------------------------------------
Tiered Data Protection Made Simple
http://www.overlandstorage.com/
----------------------------------------------------


From gop at us.ibm.com  Wed Dec 19 08:19:35 2007
From: gop at us.ibm.com (George Penokie)
Date: Wed, 19 Dec 2007 10:19:35 -0600
Subject: Todays SAM-4 LB meeting information
Message-ID: <mailman.845.1441607324.22512.t10@sandbox.t10.org>

Formatted message: <A HREF="r0712190_f.htm">HTML-formatted message</A>

This a reminder of the SAM-4 letter ballot meeting that will be held today 
(12/19). Meeting informatin is as follows: 
12/17/2007 - 03:00 pm -  05:00 pm (central time) 
Audio Conference Access Numbers
USA: 770-615-1254 (Note: this number may be a problem in some locations), 
Tie-Line 421-0038 or 1-877-421-0038
Passcode: 198458 
The video information of the call on 12/19/2007 is as follows: 
Event number
1573115
Event room
Public Meeting Room
Event date and time
12/19/2007 3:00 PM
Duration
150 minutes
Presenter key 
EHWJHC7PSF
https://<a href="http://www.rooms.hp.com/attend/default.aspx?key=EHWJHC7PSF">www.rooms.hp.com/attend/default.aspx?key=EHWJHC7PSF 
Participant key 
EPDB3TEY7F
https://<a href="http://www.rooms.hp.com/attend/default.aspx?key=EPDB3TEY7F">www.rooms.hp.com/attend/default.aspx?key=EPDB3TEY7F 
Bye for now,
George Penokie
Dept 9A8 030-3 A410
E-Mail:    gop at us.ibm.com
Internal:  553-5208


From Alvin.Cox at seagate.com  Wed Dec 19 11:02:26 2007
From: Alvin.Cox at seagate.com (Alvin.Cox at seagate.com)
Date: Wed, 19 Dec 2007 13:02:26 -0600
Subject: Reminder, SAS PHY WG call, Dec 20, 10:00am CST
Message-ID: <mailman.846.1441607324.22512.t10@sandbox.t10.org>

Formatted message: <A HREF="r0712191_f.htm">HTML-formatted message</A>

Conference calls on Thursday at 10:00 am Central time.
Next conference call: 12/20/07 
Additional calls:
January 3, 2008
January 10, 2008
Toll Free Dial in Number: (877)810-9442 
International Access/Caller Paid Dial In Number: (636)651-3190 
PARTICIPANT CODE: 3243413 
Webex information: 
https://seagate.webex.com/seagate 
Topic: SAS-2 PHY WG 
Date: Thursday 
Time: 10:00 am, Central Standard Time
Meeting number: 826 515 680 
Meeting password: 6gbpsSAS 
Agenda:
1. Proposed Cable Tables for SAS2 6Gbs Phy [McSorley] 
http://www.t10.org/ftp/t10/document.07/07-471r0.pdf
2. Description of SSC profile allowed discontinuities. [Hernandez, Fortin] 
http://www.t10.org/ftp/t10/document.08/08-027r1.pdf
3. SAS-2 Interconnect Signal-to-Noise Ratio Study [Olawsky] 
http://www.t10.org/ftp/t10/document.07/07-484r0.pdf
4. SAS-2 Receiver Device Physical Testing [Witt, Bari] 
http://www.t10.org/ftp/t10/document.07/07-486r1.pdf
5. Refine/provide status on simulation technology. [Jenkins, Newman]
6. SAS-2: Remove restrictions for SSC [Houlder, Cox]
http://www.t10.org/ftp/t10/document.08/08-014r1.pdf
7. SAS-2 6Gbps PHY specification [Cox]
http://www.t10.org/ftp/t10/document.07/07-339r7.pdf
Alvin Cox
Seagate Technology, LLC
Cell 405-206-4809


From roweber at IEEE.org  Wed Dec 19 14:01:33 2007
From: roweber at IEEE.org (Ralph Weber)
Date: Wed, 19 Dec 2007 16:01:33 -0600
Subject: 08-034r0 -- fixes for 06-362r7 (error history)
Message-ID: <mailman.847.1441607324.22512.t10@sandbox.t10.org>

* From the T10 Reflector (t10 at t10.org), posted by:
* Ralph Weber <roweber at ieee.org>
*
About seven pages of substantial problems were discovered
during incorporation of 06-362r7 into SPC-4. This are
chronicled in:
http://www.t10.org/ftp/t10/document.08/08-034r0.pdf
In recognition of the controversy which accompanied the
development of 06-362r7, 08-034r0 has been uploaded with
preliminary subclause and table numbers. These will be
corrected in an r1 posting as soon as SPC-4 r12 is finished.
However, these one-off nits should not prevent those with
true error history ardor from sharpening their spears for
the January CAP WG.
All the best,
.Ralph
*
* For T10 Reflector information, send a message with
* 'info t10' (no quotes) in the message body to majordomo at t10.org


From Rrose at tandbergdata.com  Wed Dec 19 14:20:53 2007
From: Rrose at tandbergdata.com (Rose, Roger)
Date: Wed, 19 Dec 2007 15:20:53 -0700
Subject: ADI - SMC tape alerts using ADI bridging (re proposal 06-420r2 and    smc3r09)
Message-ID: <mailman.848.1441607324.22512.t10@sandbox.t10.org>

Formatted message: <A HREF="r0712193_f.htm">HTML-formatted message</A>

This is currently covered by ADC section 4.2.6 and ADC-2 Rev 8 section
4.6.
>From ADC-2:
4.6 TapeAlert application client interface
The ADC device server supports a modified version of TapeAlert specified
in SSC-2. As supported by the ADC device server, the TapeAlert flags
represent states, and the state flags are not set to zero upon retrieval
of the TapeAlert Response log page (see 6.1.3). Instead, the state flags
are set to zero upon a change of the condition involved with the state
(see table 5).
-roger rose
 Product Test, Tandberg Data
________________________________
From: owner-t10 at t10.org [mailto:owner-t10 at t10.org] On Behalf Of
GBarton at overlandstorage.com
Sent: Tuesday, December 18, 2007 3:07 PM
To: curtis.ballard at hp.com; michael_banther at hp.com; kdbutt at us.ibm.com;
halvard.eriksen at tandbergstorage.com; PayneR at iomega.com;
Paul.Stone at Quantum.com; paul.suhler at Quantum.com
Cc: t10 at t10.org
Subject: ADI - SMC tape alerts using ADI bridging (re proposal 06-420r2
and smc3r09)
In reviewing Michael Banther's proposal for tape alert flag (06-420r2),
it occurred to me that there is a problem with SMC tape alerts in
general if ADI bridging is being used for host access to the library. 
smc3r09 clause 5.2.2 third paragraph defines deactivations for tape
alerts. Numbered list 1) states "after the TapeAlert log page is read.
The TapeAlert flags shall be deactivated on a per-initiator basis such
that active flags are available for other initiators; ".   
and in proposal 06-420r2 clause 5.4.4 last paragraph, the same statement
is made with "should" instead of "shall". 
Since a library device using ADI bridging is not aware of initiators,
the library cannot clear the flags on a per initiator basis. Does this
mean the DT device must cache the tape alert log page and keep track of
the reads of that log page? If so, how does the DT device know when to
cache a new page? And if the DT device handles the tape alert log page
on a per initiator basis, how does the library know when to clear the
flags? As far as I can tell, there is no mechanism to handle this. 
Even if proposal 06-420r2 is not incorporated into smc3, the problem
still exists. 
regards, 
Geoffrey L. Barton
Overland Storage
----------------------------------------------------
Tiered Data Protection Made Simple
http://www.overlandstorage.com/
----------------------------------------------------


From GBarton at overlandstorage.com  Wed Dec 19 14:56:35 2007
From: GBarton at overlandstorage.com (GBarton at overlandstorage.com)
Date: Wed, 19 Dec 2007 14:56:35 -0800
Subject: ADI - SMC tape alerts using ADI bridging (re proposal 06-420r2 and
    smc3r09)
Message-ID: <mailman.849.1441607324.22512.t10@sandbox.t10.org>

Formatted message: <A HREF="r0712194_f.htm">HTML-formatted message</A>

roger,
I think what you are talking about is the TapeAlert for the DT device 
(tape drive) as specified in ssc2 that the library can use to track and/or 
report problems in it's tape drives. I am talking about the library 
TapAlerts defined in smc2 and currently smc3 and referred to in proposal 
06-420r2. Currently, log page 12h TapeAlert Response Log Page is not 
currently specified in smc2 or smc3. Rather, log page 2Eh TapeAlert Log 
Page. If the host access to the library is through the ADI bridge, the 
host (or hosts) can request log page 2Eh. There is currently no mechanism 
using ADI bridging to clear the flags at the library on a per I-T nexus 
basis, since the library has no visibility of the initiator. The DT device 
(tape drive) can keep track of which initiators have requested page 2Eh, 
but there is no mechanism to keep the tape drive up to date on current 
tape alerts set, unless the DT device passes the log sense command through 
the bridge (which will clear the flags in the library) and intercepts the 
log page and updates cached values accordingly. Is this being done by tape 
drives? I have not run an experiment to find out.
Geoffrey L. Barton
Overland Storage
4820 Overland Ave.
San Diego, CA 92123
858 974-4586
gbarton at overlandstorage.com
"Rose, Roger" <Rrose at tandbergdata.com> 
12/19/2007 02:21 PM
To
<GBarton at overlandstorage.com>, <t10 at t10.org>
cc
Subject
RE: ADI - SMC tape alerts using ADI bridging (re proposal 06-420r2 and 
smc3r09)
This is currently covered by ADC section 4.2.6 and ADC-2 Rev 8 section 
4.6.
>From ADC-2:
4.6 TapeAlert application client interface
The ADC device server supports a modified version of TapeAlert specified 
in SSC-2. As supported by the ADC device server, the TapeAlert flags 
represent states, and the state flags are not set to zero upon retrieval 
of the TapeAlert Response log page (see 6.1.3). Instead, the state flags 
are set to zero upon a change of the condition involved with the state 
(see table 5).
-roger rose
 Product Test, Tandberg Data
From: owner-t10 at t10.org [mailto:owner-t10 at t10.org] On Behalf Of 
GBarton at overlandstorage.com
Sent: Tuesday, December 18, 2007 3:07 PM
To: curtis.ballard at hp.com; michael_banther at hp.com; kdbutt at us.ibm.com; 
halvard.eriksen at tandbergstorage.com; PayneR at iomega.com; 
Paul.Stone at Quantum.com; paul.suhler at Quantum.com
Cc: t10 at t10.org
Subject: ADI - SMC tape alerts using ADI bridging (re proposal 06-420r2 
and smc3r09)
In reviewing Michael Banther's proposal for tape alert flag (06-420r2), it 
occurred to me that there is a problem with SMC tape alerts in general if 
ADI bridging is being used for host access to the library. 
smc3r09 clause 5.2.2 third paragraph defines deactivations for tape 
alerts. Numbered list 1) states "after the TapeAlert log page is read. The 
TapeAlert flags shall be deactivated on a per-initiator basis such that 
active flags are available for other initiators; ".   
and in proposal 06-420r2 clause 5.4.4 last paragraph, the same statement 
is made with "should" instead of "shall". 
Since a library device using ADI bridging is not aware of initiators, the 
library cannot clear the flags on a per initiator basis. Does this mean 
the DT device must cache the tape alert log page and keep track of the 
reads of that log page? If so, how does the DT device know when to cache a 
new page? And if the DT device handles the tape alert log page on a per 
initiator basis, how does the library know when to clear the flags? As far 
as I can tell, there is no mechanism to handle this. 
Even if proposal 06-420r2 is not incorporated into smc3, the problem still 
exists. 
regards, 
Geoffrey L. Barton
Overland Storage
----------------------------------------------------
Tiered Data Protection Made Simple
http://www.overlandstorage.com/
----------------------------------------------------


From curtis.stevens at wdc.com  Wed Dec 19 14:51:40 2007
From: curtis.stevens at wdc.com (Curtis Stevens)
Date: Wed, 19 Dec 2007 14:51:40 -0800
Subject: January Meeting Week
Message-ID: <mailman.850.1441607324.22512.t10@sandbox.t10.org>

Formatted message: <A HREF="r0712195_f.htm">HTML-formatted message</A>

I have extended the room block through this Friday 21-Dec.  If you are
interested in booking into the room block, please make your reservations
before Friday.	The room block is used up for some of the days.  Please send
me an E-Mail if the system indicates that there is no availability for one
of your nights.  I will try and add a couple more room nights to the block.
This link provides reservation instructions:
http://www.t10.org/ftp/t10/announce/ann-m083.pdf.
-------------------------------------------------
Curtis E. Stevens
20511 Lake Forest Drive #C-214D
Lake Forest, California 92630
Phone: 949-672-7933
Cell: 949-307-5050
E-Mail: Curtis.Stevens at WDC.com  


From Mike.Jenkins at lsi.com  Wed Dec 19 15:26:44 2007
From: Mike.Jenkins at lsi.com (Jenkins, Mike)
Date: Wed, 19 Dec 2007 16:26:44 -0700
Subject: Reminder, SAS PHY WG call, Dec 20, 10:00am CST
Message-ID: <mailman.851.1441607324.22512.t10@sandbox.t10.org>

Formatted message: <A HREF="r0712196_f.htm">HTML-formatted message</A>

Alvin & all,
I will be on sabbatical for the next two meetings, so I will not be able
to provide any further input on agenda item 5.	However, anyone who
wishes can look at http://www.t11.org/ftp/t11/pub/fc/pi-4/07-706v0.pdf
and http://www.t11.org/ftp/t11/pub/fc/pi-4/07-706v0.zip.  
I would also like to take this opportunity to state my opposition to the
change in reference TX output level in T10/07-486r1.  We have previously
set the peak-peak reference TX output at 1000 mV (800mV VMA).  The
particular motivation was to not overspecify end devices with low cost
packages.  I suggest that no application will drive a 10 meter cable
with the ~600mV VMA implied by Table 73 in 07-486r1.
Happy Holidays everyone.
Regards,
Mike
________________________________
From: owner-t10 at t10.org [mailto:owner-t10 at t10.org] On Behalf Of
Alvin.Cox at seagate.com
Sent: Wednesday, December 19, 2007 11:02 AM
To: t10 at t10.org
Subject: Reminder, SAS PHY WG call, Dec 20, 10:00am CST
Conference calls on Thursday at 10:00 am Central time. 
Next conference call: 12/20/07 
Additional calls: 
January 3, 2008 
January 10, 2008 
Toll Free Dial in Number: (877)810-9442 
International Access/Caller Paid Dial In Number: (636)651-3190 
PARTICIPANT CODE: 3243413 
Webex information: 
https://seagate.webex.com/seagate 
Topic: SAS-2 PHY WG 
Date: Thursday 
Time: 10:00 am, Central Standard Time 
Meeting number: 826 515 680 
Meeting password: 6gbpsSAS 
Agenda: 
1. Proposed Cable Tables for SAS2 6Gbs Phy [McSorley] 
http://www.t10.org/ftp/t10/document.07/07-471r0.pdf
<http://www.t10.org/ftp/t10/document.07/07-471r0.pdf&gt;  
2. Description of SSC profile allowed discontinuities. [Hernandez,
Fortin] 
http://www.t10.org/ftp/t10/document.08/08-027r1.pdf
<http://www.t10.org/ftp/t10/document.08/08-027r1.pdf&gt;  
3. SAS-2 Interconnect Signal-to-Noise Ratio Study [Olawsky] 
http://www.t10.org/ftp/t10/document.07/07-484r0.pdf
<http://www.t10.org/ftp/t10/document.07/07-484r0.pdf&gt;  
4. SAS-2 Receiver Device Physical Testing [Witt, Bari] 
http://www.t10.org/ftp/t10/document.07/07-486r1.pdf
<http://www.t10.org/ftp/t10/document.07/07-486r1.pdf&gt;  
5. Refine/provide status on simulation technology. [Jenkins, Newman]
6. SAS-2: Remove restrictions for SSC [Houlder, Cox] 
http://www.t10.org/ftp/t10/document.08/08-014r1.pdf
<http://www.t10.org/ftp/t10/document.08/08-014r1.pdf&gt;  
7. SAS-2 6Gbps PHY specification [Cox] 
http://www.t10.org/ftp/t10/document.07/07-339r7.pdf
<http://www.t10.org/ftp/t10/document.07/07-339r7.pdf&gt;  
Alvin Cox
Seagate Technology, LLC
Cell 405-206-4809
E-Mail	alvin.cox at seagate.com


From mikeb at bustrace.com  Wed Dec 19 15:55:23 2007
From: mikeb at bustrace.com (Mike Berhan)
Date: Wed, 19 Dec 2007 15:55:23 -0800
Subject: MMC - Inquiry Data for ATAPI and USB Drives
Message-ID: <mailman.852.1441607324.22512.t10@sandbox.t10.org>

* From the T10 Reflector (t10 at t10.org), posted by:
* "Mike Berhan" <mikeb at bustrace.com>
*
MMC4,5,6 define certain Inquiry bit fields that should be returned for ATAPI
and USB devices.  You can see these values in Table 328 in mmc6r01.pdf.
1.)  Response Data Format
MMC states that the device shall return 0011b.	I am sure this is a typo
going back to MMC-4.  It should be 0010b and would then match SPC and Mt.
Fuji.
2.)  AERC, TrmTsk, NormACA, HiSup
These four bits comprise bits 4-7 of byte 2 of the Inquiry page.  MMC 4, 5,
and 6 define that these four bits should be returned zero for ATAPI and USB
logical units.	Mt. Fuji documents two formats.  One is for SCSI devices,
the other for ATAPI devices.  For ATAPI devices, bits 4-7 are defined as the
"ATAPI Transport Version."  In the Mt. Fuji annex, it goes on to say
"The AERC, TrmTsk and NormACA are in conflict with the current definition of
the INQUIRY data. This
specification specifies the ATAPI Transport version in place of these bits."
Unless I missed something, these two specifications conflict in their
Inquiry definitions for ATAPI devices.	Table 328 in mmc6r01.pdf conflicts
with Table 499 in fuji7r094.pdf.
I have compared the Inquiry pages of 30 ATAPI CD/DVD devices (from old to
new).  All of them follow the Mt. Fuji specification for ATAPI devices.
Should MMC be adjusted to correctly reflect the ATAPI format?
Alternatively, should Mt. Fuji be brought in compliance with SPC?
Regards,
-------
Mike Berhan
busTRACE Technologies
9700 Village Center Drive
Suite 50-F
Granite Bay, CA  95746
916.773.4554 phone
916.218.6283 fax
http://www.bustrace.com
*
* For T10 Reflector information, send a message with
* 'info t10' (no quotes) in the message body to majordomo at t10.org


From Rrose at tandbergdata.com  Wed Dec 19 16:00:50 2007
From: Rrose at tandbergdata.com (Rose, Roger)
Date: Wed, 19 Dec 2007 17:00:50 -0700
Subject: ADI - SMC tape alerts using ADI bridging (re proposal 06-420r2 and    smc3r09)
Message-ID: <mailman.853.1441607324.22512.t10@sandbox.t10.org>

Formatted message: <A HREF="r0712198_f.htm">HTML-formatted message</A>

Geoffrey,
I suppose I may be confused on which set of tape alerts.  (I tend to be
confused fairly easily.)
I haven't run tests on this either, but I doubt whether any ADI Bridge
drives cache the Library Log Sense data to allow per-initiator clearing.
There currently isn't any obvious mechanism to indicate that the Log
Sense data has changed and the cache needs refreshed.  
The technique you've described to pass the command through and update
the cache might be workable.  It appears to have an odd corner case:
If the Remote SMC Device Server clears Tape Alert bits upon sending them
to the bridge, then upon the next retrieval the bridge won't be able to
tell whether (a) the bits are still cleared from the last retrieval or
(b) the underlying condition has been cleared (e.g. by performing the
specified corrective action) and shouldn't be reported to other
initiators anymore.
If the Remote SMC Device Server doesn't clear Tape Alert bits upon
sending them to the bridge, then upon the next retrieval the bridge
won't be able to tell whether (a) the condition persists and should not
be reported again to initiators that have already seen it or (b) the
underlying condition was cleared and has actually occurred again.
I suspect that supporting per-initiator Tape Alert would require adding
another flag to Notify data Transfer Device or something along those
lines.	
-roger rose 
 Product Test, Tandberg Data 
________________________________
From: GBarton at overlandstorage.com [mailto:GBarton at overlandstorage.com] 
Sent: Wednesday, December 19, 2007 3:57 PM
To: t10 at t10.org
Cc: Rose, Roger
Subject: RE: ADI - SMC tape alerts using ADI bridging (re proposal
06-420r2 and smc3r09)
roger, 
I think what you are talking about is the TapeAlert for the DT device
(tape drive) as specified in ssc2 that the library can use to track
and/or report problems in it's tape drives. I am talking about the
library TapAlerts defined in smc2 and currently smc3 and referred to in
proposal 06-420r2. Currently, log page 12h TapeAlert Response Log Page
is not currently specified in smc2 or smc3. Rather, log page 2Eh
TapeAlert Log Page. If the host access to the library is through the ADI
bridge, the host (or hosts) can request log page 2Eh. There is currently
no mechanism using ADI bridging to clear the flags at the library on a
per I-T nexus basis, since the library has no visibility of the
initiator. The DT device (tape drive) can keep track of which initiators
have requested page 2Eh, but there is no mechanism to keep the tape
drive up to date on current tape alerts set, unless the DT device passes
the log sense command through the bridge (which will clear the flags in
the library) and intercepts the log page and updates cached values
accordingly. Is this being done by tape drives? I have not run an
experiment to find out. 
Geoffrey L. Barton
Overland Storage
4820 Overland Ave.
San Diego, CA 92123
858 974-4586
gbarton at overlandstorage.com 
"Rose, Roger" <Rrose at tandbergdata.com> 
12/19/2007 02:21 PM 
To
<GBarton at overlandstorage.com>, <t10 at t10.org> 
cc
Subject
RE: ADI - SMC tape alerts using ADI bridging (re proposal 06-420r2 and
smc3r09)
This is currently covered by ADC section 4.2.6 and ADC-2 Rev 8 section
4.6. 
>From ADC-2: 
4.6 TapeAlert application client interface 
The ADC device server supports a modified version of TapeAlert specified
in SSC-2. As supported by the ADC device server, the TapeAlert flags
represent states, and the state flags are not set to zero upon retrieval
of the TapeAlert Response log page (see 6.1.3). Instead, the state flags
are set to zero upon a change of the condition involved with the state
(see table 5). 
-roger rose 
 Product Test, Tandberg Data 
________________________________
From: owner-t10 at t10.org [mailto:owner-t10 at t10.org] On Behalf Of
GBarton at overlandstorage.com
Sent: Tuesday, December 18, 2007 3:07 PM
To: curtis.ballard at hp.com; michael_banther at hp.com; kdbutt at us.ibm.com;
halvard.eriksen at tandbergstorage.com; PayneR at iomega.com;
Paul.Stone at Quantum.com; paul.suhler at Quantum.com
Cc: t10 at t10.org
Subject: ADI - SMC tape alerts using ADI bridging (re proposal 06-420r2
and smc3r09)
In reviewing Michael Banther's proposal for tape alert flag (06-420r2),
it occurred to me that there is a problem with SMC tape alerts in
general if ADI bridging is being used for host access to the library. 
smc3r09 clause 5.2.2 third paragraph defines deactivations for tape
alerts. Numbered list 1) states "after the TapeAlert log page is read.
The TapeAlert flags shall be deactivated on a per-initiator basis such
that active flags are available for other initiators; ".   
and in proposal 06-420r2 clause 5.4.4 last paragraph, the same statement
is made with "should" instead of "shall". 
Since a library device using ADI bridging is not aware of initiators,
the library cannot clear the flags on a per initiator basis. Does this
mean the DT device must cache the tape alert log page and keep track of
the reads of that log page? If so, how does the DT device know when to
cache a new page? And if the DT device handles the tape alert log page
on a per initiator basis, how does the library know when to clear the
flags? As far as I can tell, there is no mechanism to handle this. 
Even if proposal 06-420r2 is not incorporated into smc3, the problem
still exists. 
regards, 
Geoffrey L. Barton
Overland Storage
----------------------------------------------------
Tiered Data Protection Made Simple
http://www.overlandstorage.com/
---------------------------------------------------- 


From kdbutt at us.ibm.com  Wed Dec 19 17:49:47 2007
From: kdbutt at us.ibm.com (Kevin D Butt)
Date: Wed, 19 Dec 2007 18:49:47 -0700
Subject: ADI - SMC tape alerts using ADI bridging (re proposal 06-420r2 and
    smc3r09)
Message-ID: <mailman.854.1441607324.22512.t10@sandbox.t10.org>

Formatted message: <A HREF="r0712199_f.htm">HTML-formatted message</A>

I suspect that all implementers have only one set of SMC tapealerts and 
that they get cleared when the first initiator reads them.  I have not 
checked our implementation, but this is my guess since there is no way to 
communicate I_T nexus to the SMC device.
Kevin D. Butt
SCSI & Fibre Channel Architect, Tape Firmware
MS 6TYA, 9000 S. Rita Rd., Tucson, AZ 85744
Tel: 520-799-2869 / 520-799-5280
Fax: 520-799-2723 (T/L:321)
Email address: kdbutt at us.ibm.com
http://www-03.ibm.com/servers/storage/ 
"Rose, Roger" <Rrose at tandbergdata.com> 
Sent by: owner-t10 at t10.org
12/19/2007 05:00 PM
To
<t10 at t10.org>, <GBarton at overlandstorage.com>
cc
Subject
RE: ADI - SMC tape alerts using ADI bridging (re proposal 06-420r2 and 
smc3r09)
Geoffrey,
I suppose I may be confused on which set of tape alerts.  (I tend to be 
confused fairly easily.)
I haven't run tests on this either, but I doubt whether any ADI Bridge 
drives cache the Library Log Sense data to allow per-initiator clearing. 
There currently isn't any obvious mechanism to indicate that the Log Sense 
data has changed and the cache needs refreshed. 
The technique you've described to pass the command through and update the 
cache might be workable.  It appears to have an odd corner case:
If the Remote SMC Device Server clears Tape Alert bits upon sending them 
to the bridge, then upon the next retrieval the bridge won't be able to 
tell whether (a) the bits are still cleared from the last retrieval or (b) 
the underlying condition has been cleared (e.g. by performing the 
specified corrective action) and shouldn't be reported to other initiators 
anymore.
If the Remote SMC Device Server doesn't clear Tape Alert bits upon sending 
them to the bridge, then upon the next retrieval the bridge won't be able 
to tell whether (a) the condition persists and should not be reported 
again to initiators that have already seen it or (b) the underlying 
condition was cleared and has actually occurred again.
I suspect that supporting per-initiator Tape Alert would require adding 
another flag to Notify data Transfer Device or something along those 
lines. 
-roger rose 
 Product Test, Tandberg Data 
From: GBarton at overlandstorage.com [mailto:GBarton at overlandstorage.com] 
Sent: Wednesday, December 19, 2007 3:57 PM
To: t10 at t10.org
Cc: Rose, Roger
Subject: RE: ADI - SMC tape alerts using ADI bridging (re proposal 
06-420r2 and smc3r09)
roger, 
I think what you are talking about is the TapeAlert for the DT device 
(tape drive) as specified in ssc2 that the library can use to track and/or 
report problems in it's tape drives. I am talking about the library 
TapAlerts defined in smc2 and currently smc3 and referred to in proposal 
06-420r2. Currently, log page 12h TapeAlert Response Log Page is not 
currently specified in smc2 or smc3. Rather, log page 2Eh TapeAlert Log 
Page. If the host access to the library is through the ADI bridge, the 
host (or hosts) can request log page 2Eh. There is currently no mechanism 
using ADI bridging to clear the flags at the library on a per I-T nexus 
basis, since the library has no visibility of the initiator. The DT device 
(tape drive) can keep track of which initiators have requested page 2Eh, 
but there is no mechanism to keep the tape drive up to date on current 
tape alerts set, unless the DT device passes the log sense command through 
the bridge (which will clear the flags in the library) and intercepts the 
log page and updates cached values accordingly. Is this being done by tape 
drives? I have not run an experiment to find out. 
Geoffrey L. Barton
Overland Storage
4820 Overland Ave.
San Diego, CA 92123
858 974-4586
gbarton at overlandstorage.com 
"Rose, Roger" <Rrose at tandbergdata.com> 
12/19/2007 02:21 PM 
To
<GBarton at overlandstorage.com>, <t10 at t10.org> 
cc
Subject
RE: ADI - SMC tape alerts using ADI bridging (re proposal 06-420r2 and 
smc3r09)
This is currently covered by ADC section 4.2.6 and ADC-2 Rev 8 section 
4.6. 
>From ADC-2: 
4.6 TapeAlert application client interface 
The ADC device server supports a modified version of TapeAlert specified 
in SSC-2. As supported by the ADC device server, the TapeAlert flags 
represent states, and the state flags are not set to zero upon retrieval 
of the TapeAlert Response log page (see 6.1.3). Instead, the state flags 
are set to zero upon a change of the condition involved with the state 
(see table 5). 
-roger rose 
 Product Test, Tandberg Data 
From: owner-t10 at t10.org [mailto:owner-t10 at t10.org] On Behalf Of 
GBarton at overlandstorage.com
Sent: Tuesday, December 18, 2007 3:07 PM
To: curtis.ballard at hp.com; michael_banther at hp.com; kdbutt at us.ibm.com; 
halvard.eriksen at tandbergstorage.com; PayneR at iomega.com; 
Paul.Stone at Quantum.com; paul.suhler at Quantum.com
Cc: t10 at t10.org
Subject: ADI - SMC tape alerts using ADI bridging (re proposal 06-420r2 
and smc3r09)
In reviewing Michael Banther's proposal for tape alert flag (06-420r2), it 
occurred to me that there is a problem with SMC tape alerts in general if 
ADI bridging is being used for host access to the library. 
smc3r09 clause 5.2.2 third paragraph defines deactivations for tape 
alerts. Numbered list 1) states "after the TapeAlert log page is read. The 
TapeAlert flags shall be deactivated on a per-initiator basis such that 
active flags are available for other initiators; ".   
and in proposal 06-420r2 clause 5.4.4 last paragraph, the same statement 
is made with "should" instead of "shall". 
Since a library device using ADI bridging is not aware of initiators, the 
library cannot clear the flags on a per initiator basis. Does this mean 
the DT device must cache the tape alert log page and keep track of the 
reads of that log page? If so, how does the DT device know when to cache a 
new page? And if the DT device handles the tape alert log page on a per 
initiator basis, how does the library know when to clear the flags? As far 
as I can tell, there is no mechanism to handle this. 
Even if proposal 06-420r2 is not incorporated into smc3, the problem still 
exists. 
regards, 
Geoffrey L. Barton
Overland Storage
----------------------------------------------------
Tiered Data Protection Made Simple
http://www.overlandstorage.com/
---------------------------------------------------- 


From keiji_katata at post.pioneer.co.jp  Thu Dec 20 00:10:06 2007
From: keiji_katata at post.pioneer.co.jp (keiji_katata at post.pioneer.co.jp)
Date: Thu, 20 Dec 2007 17:10:06 +0900
Subject: 1/9 SWG meeting announcement at Kawasaki
Message-ID: <mailman.855.1441607324.22512.t10@sandbox.t10.org>

* From the T10 Reflector (t10 at t10.org), posted by:
* keiji_katata at post.pioneer.co.jp
*
Hello all,
Pioneer prepares a meeting room for the SWG at 1/9.
Agenda: Real-time streaming playback model
Date: 2008/1/9
Time: 10:00AM - 5:00PM
Place: 1-1, SHIN-OGURA, SAIWAI-KU, KAWASAKI-SHI KANAGAWA 212-0031, JAPAN
TEL: 81-44-580-3211
Map:
http://pioneer.jp/corp/profile/map/kawasaki/index-e.html
Registration by 2008/1/7 is required.
13 people of the beginning will have free lunch in the building.
Best regards,
Keiji Katata
PIONEER CORP.
TEL +81-49-279-2387
*
* For T10 Reflector information, send a message with
* 'info t10' (no quotes) in the message body to majordomo at t10.org


From keiji_katata at post.pioneer.co.jp  Thu Dec 20 00:23:57 2007
From: keiji_katata at post.pioneer.co.jp (keiji_katata at post.pioneer.co.jp)
Date: Thu, 20 Dec 2007 17:23:57 +0900
Subject: Preliminary Information 1/14 SWG meeting at T10 place
Message-ID: <mailman.856.1441607324.22512.t10@sandbox.t10.org>

* From the T10 Reflector (t10 at t10.org), posted by:
* keiji_katata at post.pioneer.co.jp
*
Hello all,
Now kindly Curtis Stevens of WDC is checking a meeting room availability at
Embassy Suites T10 place.
It might be OK. So if you want to attend the 1/14 SWG, you may adjust your
hotel
room. The room block and rate will end on Friday night (21-DEC).
Best regards,
Keiji Katata
PIONEER CORP.
TEL +81-49-279-2387
*
* For T10 Reflector information, send a message with
* 'info t10' (no quotes) in the message body to majordomo at t10.org


From keiji_katata at post.pioneer.co.jp  Wed Dec 19 23:53:33 2007
From: keiji_katata at post.pioneer.co.jp (keiji_katata at post.pioneer.co.jp)
Date: Thu, 20 Dec 2007 16:53:33 +0900
Subject: Posted: Meeting Minutes and delivered documents
Message-ID: <mailman.857.1441607324.22512.t10@sandbox.t10.org>

* From the T10 Reflector (t10 at t10.org), posted by:
* keiji_katata at post.pioneer.co.jp
*
Hello all,
I posted Meeting Minutes and delivered documents on ftp.
<ftp.avc-pioneer.com&gt;
/Mtfuji_7/Minutes
 MinNov07.pdf
 DraftMinDec18.pdf
/Mtfuji_7/Proposal/Dec07/Microsoft
 Example of Command Data for_Speed_Control_Proposal.xls
 Example_of_Use_for_Speed_Control_Proposal.pdf
 Speed control examples Nero.ppt
 Speed control examples Nero.xls
I'm sorry that I could not attend this meeting due to disease. It is becoming
better now.
Ai san, thank you for taking the chairmanship.
Best regards,
Keiji Katata
PIONEER CORP.
*
* For T10 Reflector information, send a message with
* 'info t10' (no quotes) in the message body to majordomo at t10.org


From roweber at ieee.org  Thu Dec 20 07:31:34 2007
From: roweber at ieee.org (Ralph Weber)
Date: Thu, 20 Dec 2007 09:31:34 -0600
Subject: New ASC
Message-ID: <mailman.858.1441607324.22512.t10@sandbox.t10.org>

* From the T10 Reflector (t10 at t10.org), posted by:
* Ralph Weber <roweber at ieee.org>
*
I have certainly added the following Additional Sense
Codes for SPC-4 r12:
00/07 -- PROGRAMMABLE EARLY WARNING DETECTED
00/1E -- CONFLICTING SA CREATION REQUEST
04/13 -- LOGICAL UNIT NOT READY, SA CREATION IN PROGRESS
24/08 -- INVALID XCDB
2A/0A -- ERROR HISTORY I_T NEXUS CLEARED
2A/0B -- ERROR HISTORY SNAPSHOT RELEASED
2A/14 -- SA CREATION CAPABILITIES DATA HAS CHANGED
74/0C -- UNABLE TO DECRYPT PARAMETER LIST
74/10 -- SA CREATION PARAMETER VALUE INVALID
74/11 -- SA CREATION PARAMETER VALUE REJECTED
74/12 -- INVALID SA USAGE
74/30 -- SA CREATION PARAMETER NOT SUPPORTED
74/40 -- AUTHENTICATION FAILED
74/79 -- SECURITY CONFLICT IN TRANSLATED DEVICE
I also have indications of some older changes, but I cannot
verify what was added back in May. If your favorite new ASC
is not in the above list, please check the web site:
http://www.t10.org/lists/2asc.htm
If you still cannot find the ASC, please let me know so
I can make the change before SPC-4 r12 goes to press
sometime next week.
Thanks,
.Ralph
*
* For T10 Reflector information, send a message with
* 'info t10' (no quotes) in the message body to majordomo at t10.org


From Quicksall_SCSI at Bellsouth.net  Thu Dec 20 09:07:54 2007
From: Quicksall_SCSI at Bellsouth.net (Eddy Quicksall)
Date: Thu, 20 Dec 2007 12:07:54 -0500
Subject: OSD Perform Scsi Command ( Inquiry )
Message-ID: <mailman.859.1441607324.22512.t10@sandbox.t10.org>

Formatted message: <A HREF="r0712204_f.htm">HTML-formatted message</A>

According to SAM4r13b 5.8.7 2nd instance of 'a', an INQUIRY should not report
a Unit Attention; what about an INQUIRY given via PERFORM SCSI COMMAND? My
guess is that it should report a Unit Attention (if pending) because the
PERFORM SCSI COMMAND fits into the category of "If a command other than
INQUIRY ..." (see SAM4r13b 5.8.7 2nd instance of 'e').
Am I correct?


From gop at us.ibm.com  Thu Dec 20 12:41:33 2007
From: gop at us.ibm.com (George Penokie)
Date: Thu, 20 Dec 2007 14:41:33 -0600
Subject: Friday 12/21 - SAM-4 LB meeting information
Message-ID: <mailman.860.1441607324.22512.t10@sandbox.t10.org>

Formatted message: <A HREF="r0712205_f.htm">HTML-formatted message</A>

This a reminder of the SAM-4 letter ballot meeting that will be held 
Friday (12/21). Meeting informatin is as follows: 
12/21/2007 - 10:00 am -  noon (central time) 
Audio Conference Access Numbers
USA: 770-615-1254 (Note: this number may be a problem in some locations), 
Tie-Line 421-0038 or 1-877-421-0038
Passcode: 198458 
The video information of the call on 12/21/2007 is as follows: 
Friday:
Event number
1573118
Event room
Public Meeting Room
Event name
T10 SAM-4 LB
Event date and time
12/21/2007 10:00 AM
Duration
150 minutes
Event size 
5
Event Keys
Presenter key 
EHFYY7D7BE
https://<a href="http://www.rooms.hp.com/attend/default.aspx?key=EHFYY7D7BE">www.rooms.hp.com/attend/default.aspx?key=EHFYY7D7BE 
Participant key 
EPRMVM7D6S
https://<a href="http://www.rooms.hp.com/attend/default.aspx?key=EPRMVM7D6S">www.rooms.hp.com/attend/default.aspx?key=EPRMVM7D6S 
Bye for now,
George Penokie
Dept 9A8 030-3 A410
E-Mail:    gop at us.ibm.com
Internal:  553-5208


From keiji_katata at post.pioneer.co.jp  Thu Dec 20 20:49:57 2007
From: keiji_katata at post.pioneer.co.jp (keiji_katata at post.pioneer.co.jp)
Date: Fri, 21 Dec 2007 13:49:57 +0900
Subject: Reflector cleanup notice
Message-ID: <mailman.861.1441607324.22512.t10@sandbox.t10.org>

* From the T10 Reflector (t10 at t10.org), posted by:
* keiji_katata at post.pioneer.co.jp
*
Hello all,
The following people have bounced repeatedly and removed from mtfuji5
reflector:
ctl at arrowtwins.com
emhill at microsoft.com
They may get back on the reflector by sending a message to
majordomo at avc-pioneer.com with the following line in the message body:
subscribe mtfuji5
Best regards,
Keiji Katata
PIONEER CORP.
*
* 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  Thu Dec 20 21:43:53 2007
From: lohmeyer at t10.org (John Lohmeyer)
Date: Thu, 20 Dec 2007 22:43:53 -0700
Subject: FW: 07-454r3 comment on SMC-3 permissions
Message-ID: <mailman.862.1441607324.22512.t10@sandbox.t10.org>

Attachment #1: <A HREF="r0712207_07-454r3_smc3_comments.pdf">07-454r3_smc3_comments.pdf</A>

>
>-----Original Message-----
>From: Rod Wideman 
>Sent: Tuesday, December 18, 2007 5:51 PM
>To: 'George Penokie'; t10 at t10.org
>Cc: Sivan Tal
>Subject: 07-454r3 comment on SMC-3 permissions
>
>All,
> 
>Attached is a comment on the SMC-3 permissions proposed in 07-454, per the
Security discussion this morning.
> 
>Rod Wideman
> 
>(ignore any confidential statement that may appear below; the information
being provided is not confidential)
> 
>
>
>----------
>The information contained in this transmission may be confidential. Any
disclosure, copying, or further distribution of confidential information is
not permitted unless such privilege is explicitly granted in writing by
Quantum Corporation. Furthermore, Quantum Corporation is not responsible for
the proper and complete transmission of the substance of this communication
or for any delay in its receipt.
>
>----------
--
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


From kdbutt at us.ibm.com  Fri Dec 21 08:24:10 2007
From: kdbutt at us.ibm.com (Kevin D Butt)
Date: Fri, 21 Dec 2007 09:24:10 -0700
Subject: DS_SAI length conflict between 07-437r4 and 07-169 & SPC-4
Message-ID: <mailman.863.1441607324.22512.t10@sandbox.t10.org>

Formatted message: <A HREF="r0712210_f.htm">HTML-formatted message</A>

Ralph, David, and Matt,
All the DS_SAI values in the ESP-SCSI (07-169r5) (e.g., Table x3 ? 
ESP-SCSI data-out buffer parameter list descriptor without initialization 
vector) are shown as 4-byte values as they are in SPC-4 Table 44 ? Minimum 
SA parameters.	However 07-437r4 shows them as 8-byte values.  I think 
07-437r4 is correct and SPC-4 and 07-169 need to be modified to match.
Thanks,
Kevin D. Butt
SCSI & Fibre Channel Architect, Tape Firmware
MS 6TYA, 9000 S. Rita Rd., Tucson, AZ 85744
Tel: 520-799-2869 / 520-799-5280
Fax: 520-799-2723 (T/L:321)
Email address: kdbutt at us.ibm.com


From GBarton at overlandstorage.com  Fri Dec 21 15:06:28 2007
From: GBarton at overlandstorage.com (GBarton at overlandstorage.com)
Date: Fri, 21 Dec 2007 15:06:28 -0800
Subject: ADI - SMC tape alerts using ADI bridging (re proposal 06-420r2 and
    smc3r09)
Message-ID: <mailman.864.1441607324.22512.t10@sandbox.t10.org>

Formatted message: <A HREF="r0712211_f.htm">HTML-formatted message</A>

Kevin,
I suspect you are right. However, that still leaves problem if a 
implementer wanted to respond on a per initiator basis, as the SMC 
standard requires: smc2 clause 5.5.2 lettered list a) "after the TapeAlert 
log page is read. The TapeAlert flags shall be deactivated on a per 
initiator
basis such that active flags are available for other initiators;". The 
same statement is in smc3r09 and in proposal 06-420r2 clause 5.4.3 with 
the "shall" changed to "should" or "may" depending on the state of the 
TAPLSD bit.
Geoffrey L. Barton
Overland Storage
4820 Overland Ave.
San Diego, CA 92123
858 974-4586
gbarton at overlandstorage.com
Kevin D Butt <kdbutt at us.ibm.com> 
Sent by: owner-t10 at t10.org
12/19/2007 06:58 PM
To
"Rose, Roger" <Rrose at tandbergdata.com>
cc
GBarton at overlandstorage.com, owner-t10 at t10.org, t10 at t10.org
Subject
RE: ADI - SMC tape alerts using ADI bridging (re proposal 06-420r2 and 
smc3r09)
I suspect that all implementers have only one set of SMC tapealerts and 
that they get cleared when the first initiator reads them.  I have not 
checked our implementation, but this is my guess since there is no way to 
communicate I_T nexus to the SMC device. 
Kevin D. Butt
SCSI & Fibre Channel Architect, Tape Firmware
MS 6TYA, 9000 S. Rita Rd., Tucson, AZ 85744
Tel: 520-799-2869 / 520-799-5280
Fax: 520-799-2723 (T/L:321)
Email address: kdbutt at us.ibm.com
http://www-03.ibm.com/servers/storage/ 
"Rose, Roger" <Rrose at tandbergdata.com> 
Sent by: owner-t10 at t10.org 
12/19/2007 05:00 PM 
To
<t10 at t10.org>, <GBarton at overlandstorage.com> 
cc
Subject
RE: ADI - SMC tape alerts using ADI bridging (re proposal 06-420r2 and 
smc3r09)
Geoffrey, 
I suppose I may be confused on which set of tape alerts.  (I tend to be 
confused fairly easily.) 
I haven't run tests on this either, but I doubt whether any ADI Bridge 
drives cache the Library Log Sense data to allow per-initiator clearing. 
There currently isn't any obvious mechanism to indicate that the Log Sense 
data has changed and the cache needs refreshed.   
The technique you've described to pass the command through and update the 
cache might be workable.  It appears to have an odd corner case: 
If the Remote SMC Device Server clears Tape Alert bits upon sending them 
to the bridge, then upon the next retrieval the bridge won't be able to 
tell whether (a) the bits are still cleared from the last retrieval or (b) 
the underlying condition has been cleared (e.g. by performing the 
specified corrective action) and shouldn't be reported to other initiators 
anymore. 
If the Remote SMC Device Server doesn't clear Tape Alert bits upon sending 
them to the bridge, then upon the next retrieval the bridge won't be able 
to tell whether (a) the condition persists and should not be reported 
again to initiators that have already seen it or (b) the underlying 
condition was cleared and has actually occurred again. 
I suspect that supporting per-initiator Tape Alert would require adding 
another flag to Notify data Transfer Device or something along those 
lines.	 
-roger rose 
Product Test, Tandberg Data 
From: GBarton at overlandstorage.com [mailto:GBarton at overlandstorage.com] 
Sent: Wednesday, December 19, 2007 3:57 PM
To: t10 at t10.org
Cc: Rose, Roger
Subject: RE: ADI - SMC tape alerts using ADI bridging (re proposal 
06-420r2 and smc3r09)
roger, 
I think what you are talking about is the TapeAlert for the DT device 
(tape drive) as specified in ssc2 that the library can use to track and/or 
report problems in it's tape drives. I am talking about the library 
TapAlerts defined in smc2 and currently smc3 and referred to in proposal 
06-420r2. Currently, log page 12h TapeAlert Response Log Page is not 
currently specified in smc2 or smc3. Rather, log page 2Eh TapeAlert Log 
Page. If the host access to the library is through the ADI bridge, the 
host (or hosts) can request log page 2Eh. There is currently no mechanism 
using ADI bridging to clear the flags at the library on a per I-T nexus 
basis, since the library has no visibility of the initiator. The DT device 
(tape drive) can keep track of which initiators have requested page 2Eh, 
but there is no mechanism to keep the tape drive up to date on current 
tape alerts set, unless the DT device passes the log sense command through 
the bridge (which will clear the flags in the library) and intercepts the 
log page and updates cached values accordingly. Is this being done by tape 
drives? I have not run an experiment to find out. 
Geoffrey L. Barton
Overland Storage
4820 Overland Ave.
San Diego, CA 92123
858 974-4586
gbarton at overlandstorage.com 
"Rose, Roger" <Rrose at tandbergdata.com> 
12/19/2007 02:21 PM 
To
<GBarton at overlandstorage.com>, <t10 at t10.org> 
cc
Subject
RE: ADI - SMC tape alerts using ADI bridging (re proposal 06-420r2 and 
smc3r09)
This is currently covered by ADC section 4.2.6 and ADC-2 Rev 8 section 
4.6. 
>From ADC-2: 
4.6 TapeAlert application client interface 
The ADC device server supports a modified version of TapeAlert specified 
in SSC-2. As supported by the ADC device server, the TapeAlert flags 
represent states, and the state flags are not set to zero upon retrieval 
of the TapeAlert Response log page (see 6.1.3). Instead, the state flags 
are set to zero upon a change of the condition involved with the state 
(see table 5). 
-roger rose 
Product Test, Tandberg Data 
From: owner-t10 at t10.org [mailto:owner-t10 at t10.org] On Behalf Of 
GBarton at overlandstorage.com
Sent: Tuesday, December 18, 2007 3:07 PM
To: curtis.ballard at hp.com; michael_banther at hp.com; kdbutt at us.ibm.com; 
halvard.eriksen at tandbergstorage.com; PayneR at iomega.com; 
Paul.Stone at Quantum.com; paul.suhler at Quantum.com
Cc: t10 at t10.org
Subject: ADI - SMC tape alerts using ADI bridging (re proposal 06-420r2 
and smc3r09)
In reviewing Michael Banther's proposal for tape alert flag (06-420r2), it 
occurred to me that there is a problem with SMC tape alerts in general if 
ADI bridging is being used for host access to the library. 
smc3r09 clause 5.2.2 third paragraph defines deactivations for tape 
alerts. Numbered list 1) states "after the TapeAlert log page is read. The 
TapeAlert flags shall be deactivated on a per-initiator basis such that 
active flags are available for other initiators; ".   
and in proposal 06-420r2 clause 5.4.4 last paragraph, the same statement 
is made with "should" instead of "shall". 
Since a library device using ADI bridging is not aware of initiators, the 
library cannot clear the flags on a per initiator basis. Does this mean 
the DT device must cache the tape alert log page and keep track of the 
reads of that log page? If so, how does the DT device know when to cache a 
new page? And if the DT device handles the tape alert log page on a per 
initiator basis, how does the library know when to clear the flags? As far 
as I can tell, there is no mechanism to handle this. 
Even if proposal 06-420r2 is not incorporated into smc3, the problem still 
exists. 
regards, 
Geoffrey L. Barton
Overland Storage
----------------------------------------------------
Tiered Data Protection Made Simple
http://www.overlandstorage.com/
---------------------------------------------------- 


From kdbutt at us.ibm.com  Fri Dec 21 15:33:06 2007
From: kdbutt at us.ibm.com (Kevin D Butt)
Date: Fri, 21 Dec 2007 16:33:06 -0700
Subject: Persistent Reservation Proposal - Group Reservations
Message-ID: <mailman.865.1441607324.22512.t10@sandbox.t10.org>

Formatted message: <A HREF="r0712212_f.htm">HTML-formatted message</A>

Ray,
Thanks for joining in.	Let me summarize what I think has been said by all 
parties who have joined in these discussions.
1) (From Ray) Some applications will have trouble providing a list of 
Transport IDs.
2) (From Fred) There is a desire to allow members of a cluster that were 
not active at the creation of the reservation to join in.
3) (From Kevin) Who can join or participate in a group reservation is 
required to be controlled such that only those initiators that are part of 
the cluster (i.e. group) can join.
4) PREEMPT must be allowed (i.e., what we do cannot lock out PREEMPT or 
make it not work correctly)
5) Both Registrants Only and All Registrants types of functionality need 
to be provided for.
6) There should be an option for all target ports
If we can't require a list of Transport ID's then it seems that the 
suggested "shared secret" (not cryptographic, just some unique value that 
is protected through obfuscation) is probably the best way to do this. 
This would be something akin to requiring the same reservation key value. 
However, using the reservation key does not seem to be plausible because 
of how it is being used today.	What we need would be some different value 
that would not be reportable via a Persistent Reserve In.  This would keep 
third-party initiators from joining the reservation.  If this new Group 
Reservation Identifier (GRID) were added, that would take care of #1, #2, 
and #3 above.
For #5 above, it seems that we could provide that by adding a bit in the 
reserve command that indicates "All Participants are reservation holders". 
 If set to one, then it acts like an All Registrants.  If set to zero then 
it acts like Registrants Only.	This includes in the unregistering.
For #6 we use the ALL_TGT_PORTS bit the same as other reservations today.
Issues still to be resolved:
a) Some systems won't want to require all initiators to send a Persistent 
Reserve Out command.  Possible solution is to allow reserving multiple 
initiators if a Transport ID list is sent.  Additional initiators could 
join later if they have the GRID.  However this would make it more 
complicated and if it is not needed I would rather not add this option.
b) If the first I_T nexus sets the "All Participants are reservation 
holders" to zero when it creates the reservation and then a subsequent I_T 
nexus sets it to one, what is the behavior?  Change the type?  Reject? 
Also, what is reported in the Report Full Status if All Participants are 
reservation holders is set to zero?
c) If we go to this method of using the GRID to determine who can join, 
then the Reservation Key may or may not be different.
c-1) if the Reservation Key is different, then a PREEMPT of a Reservation 
Key will do what?
c-2) if the Reservation Key is the same, then a PREEMPT will act the same 
as an AR or RO reservation today.
c-3) Do we require the Reservation Key to be the same?
d) Does this approach still have the issues that Roger was concerned about 
(e.g., the corner cases)?
Thanks,
Kevin D. Butt
SCSI & Fibre Channel Architect, Tape Firmware
MS 6TYA, 9000 S. Rita Rd., Tucson, AZ 85744
Tel: 520-799-2869 / 520-799-5280
Fax: 520-799-2723 (T/L:321)
Email address: kdbutt at us.ibm.com
http://www-03.ibm.com/servers/storage/ 
"Raymond Gilson" <raymond_gilson at symantec.com> 
12/21/2007 12:45 PM
To
"Roger Cummings" <roger_cummings at symantec.com>, "Knight, Frederick" 
<Frederick.Knight at netapp.com>, Kevin D Butt/Tucson/IBM at IBMUS
cc
<t10 at t10.org>, Christine R Knibloe/Tucson/IBM at IBMUS
Subject
RE: Persistent Reservation Proposal - Group Reservations
Several years ago I was trying to figure out a way to introduce a "JOIN" 
function to the SPR.  The initiator would register, but that would not 
grant it access to a reservation of the "joined only" type.  To join it, 
the initiator would have to send a join SPR command -- we could add a 
"shared secret" field to the join, so that only those initiators that knew 
the secret could join.
I think we will have a great deal of trouble with a "white list" approach 
-- as an application, I have no idea what my port ID is (or anything else 
for that matter).
Would something like this make sense?
Thanks,
Ray Gilson
From: owner-t10 at t10.org [mailto:owner-t10 at t10.org] On Behalf Of Roger 
Cummings
Sent: Tuesday, December 18, 2007 10:24 AM
To: Knight, Frederick; Kevin D Butt
Cc: t10 at t10.org; Christine R Knibloe
Subject: RE: Persistent Reservation Proposal - Group Reservations
Fred,
The way you clean up from a disaster is to Preempt, that's what it's there 
for. Most of the applications that I know that will actually issue a 
Preempt make it a very special function that doesn't happen in the normal 
flow, and one app at least DOES require manual intervention of an operator 
before kicking off the preempt.
Yes, today, a Preempt has to be issued through a registered I_T nexus, but 
a registration with the SPEC_I_T bit doesn't have to come from an already 
registered initiator - see Table 33 in SPC-4, and I don't believe Kevin 
changed that in his proposal.
For the future, however we define a "group" for the purposes of new 
reservation types, we will have to make sure that an Initiator outside of 
the "group" can issue a Preempt to handle the disaster recovery case.
Regards,
Roger
From: Knight, Frederick [mailto:Frederick.Knight at netapp.com] 
Sent: Tuesday, December 18, 2007 10:56 AM
To: Roger Cummings; Kevin D Butt
Cc: t10 at t10.org; Christine R Knibloe
Subject: RE: Persistent Reservation Proposal - Group Reservations
My question has had to do with differentiating the disaster clean up
case from the non-cooperating host case.
How do I clean up from a disaster?  If all my "reserved" initiators
melt down, and there aren't any of them left anymore (because of
a site disaster, or whatever), how does some other node come along
and clean up so it can gain access?
Would it require manual intervention?  Or, is there a way in the protocol
that I can register and preempt the group reservation (does the use
of the SPEC_I_PT bit allow this as you have suggested Roger).  I
thought the SPEC_I_PT had to come from an already registered
initiator (which in a disaster, none exist anymore).
    Fred Knight
From: Roger Cummings [mailto:roger_cummings at symantec.com] 
Sent: Tuesday, December 18, 2007 10:03 AM
To: Kevin D Butt; Knight, Frederick
Cc: t10 at t10.org; Christine R Knibloe
Subject: RE: Persistent Reservation Proposal - Group Reservations
Kevin,
I'm sorry, I don't think it's as cut and dried as you make out. This gets 
into some of the corner cases that I listed in my first response.
The point to be made in response to Fred's case is that a third-party can 
create registrations for a downed initiator (via the SPEC_I_PT) bit, so 
that when it comes up again it will be able to participate in the 
reservation without having to register itself.
Also, you say that "We have made provisions for adding members once the 
reservation exists, but only one of the reservation holders can add 
another entity." Two things in response to that:
1) I didn't see any specific provision for adding members in your 
proposal, so I presume you'd just issue another RESERVE with the same type 
and the whole list of transport IDs to be included again, and thus the 
Target would have a whole lot of work to do again to set up another 
reservation.
2) I that really what you want, that an member of the existing group can 
reissue the RESERVE with a whole bunch of different TransportIDs, perhaps 
excluding some that were previously there?
Regards,
Roger
From: owner-t10 at t10.org [mailto:owner-t10 at t10.org] On Behalf Of Kevin D 
Butt
Sent: Monday, December 17, 2007 3:54 PM
To: Knight, Frederick
Cc: t10 at t10.org; Christine R Knibloe
Subject: RE: Persistent Reservation Proposal - Group Reservations
Fred, 
This is being proposed for SPC. 
There are multiple types of reservations.  In an environment where one 
node of a cluster must join later, one of the other types can be used. 
Either that or have an existing node in your cluster add the new node. The 
whole intent of this Group reservation is to lock out everybody that is 
not explicitly specified during the reserve.  We have made provisions for 
adding members once the reservation exists, but only one of the 
reservation holders can add another entity.  The new entity cannot add 
itself.  This is the whole point of reservations (i.e., lock out others 
|from doing stuff while I think I have exclusive rights). 
To put it in other word's, to allow somebody to join the reservation of 
their own accord without permission is EXACTLY what I am trying to protect 
against. 
Thanks, 
Kevin D. Butt
SCSI & Fibre Channel Architect, Tape Firmware
MS 6TYA, 9000 S. Rita Rd., Tucson, AZ 85744
Tel: 520-799-2869 / 520-799-5280
Fax: 520-799-2723 (T/L:321)
Email address: kdbutt at us.ibm.com
http://www-03.ibm.com/servers/storage/ 
"Knight, Frederick" <Frederick.Knight at netapp.com> 
12/17/2007 01:38 PM 
To
Kevin D Butt/Tucson/IBM at IBMUS 
cc
Subject
RE: Persistent Reservation Proposal - Group Reservations
Sorry, you can't require everyone to register before the reserve. 
That's like saying my whole cluster can't boot because 1 node is down. You 
need 
to have a way for a "down" initiator to join the fun after the fact. 
I helped write a host cluster product that used a shared tape (failover 
model).  The 
backup application would write to the tape.  If a system failure ever 
happened, the 
backup application would failover to a different host.	It would skip 
backwards on 
the tape for a few records, recognize where it left off, and then resume 
operation. 
BUT, for some protection, we used reservations to make sure only 1 
initiator at a 
time could access the tape.  The interesting point however, is that we 
were in the 
process of upgrading from old SCSI-2 RESERVE to using PR.  Because, we 
also 
have multiple HBAs in the host, and we wanted to be able to use more than 
1 of 
those HBAs (so we needed multiple reservations - aka PR).  Having this 
idea 
(group reservations) would have been a real nice addition. 
As for the RA/AR differences.  It seemed to be timing.	Registrants Only 
was fairly 
early on (as I remember), and so implemented by several O/S vendors. Later 
on, 
some issues were found (which got complicated spec-ees added to address), 
but also, 
the All Registrants was added (which didn't have those issues).  But, 
since there were 
implementations, it couldn't be removed like the other old PR types that 
no one ever 
used.  Anyway, I agree, they offer basically the same capabilities, but RO 
is already 
out there, and AR is probably what new implementers are using (it's easier 
to understand 
and implement from the host side).  Most of the differences are already 
documented, 
so there wouldn't be that much extra for you to write to have both types 
(which I think 
would be better than bit somewhere - do it the same way all the others are 
done).	But, 
you could also just do the AR version, and let someone else add the RO 
version if they 
want it. 
Are you proposing this for tape only? or SPC in general?  I assume SPC in 
general. 
    Fred Knight 
From: Kevin D Butt [mailto:kdbutt at us.ibm.com] 
Sent: Monday, December 17, 2007 9:51 AM
To: Roger Cummings
Cc: t10 at t10.org
Subject: RE: Persistent Reservation Proposal - Group Reservations
Roger, 
Thank you for your feedback.  I am certainly willing to entertain  other 
methods for accomplishing the end goal in an easier fashion.  I am not 
sure I understand how your proposed method makes it more backward 
compatible.  In my proposal PRin would show a different type of 
reservation and hence the application clients would not try to join the 
reservation because they don't know about the type.  In your proposal, 
application clients would not be allowed to register.  This is a deviation 
|from what they can always do today - unless there is a resource issue. 
This seems more disruptive to me.  I would assume that there would be a 
new additional sense code added for UNABLE TO REGISTER BECAUSE A GROUP 
RESERVATION IS IN PLACE (or analogous).  This would be a new thing for 
failure to register and there would be pain at the register point. Perhaps 
that is better than at the reserve point - but I would think that it would 
be better handled as a reservation conflict since that is what it is 
instead of something the application client does not understand. 
As for "all registrants" type vs. "registrants only" I didn't see where 
the difference would be interesting, but I am not opposed to providing a 
way to switch between which of these two types is done.  Whether it is 
additional types or some bit during registration etc. 
As for some of the corner cases mentioned below, if each I_T nexus that is 
supposed to be part of the group reservation is required to be registered 
before the reservation is made, and if the reservation is released when 
the last group reservation participant is unregistered, then I think we 
don't have an issue. 
I would prefer that we work together to shape a mutually beneficial 
proposal as opposed to have "competing" proposals.  I am willing to modify 
my proposal where it can be made easier and such.  I am not sold that my 
proposed method is the only way or even the best - it's just the way I 
thought of doing it.  I admit that I have always been very confused about 
the usefulness of RA and AR types.  They make absolutely no sense in the 
tape world. 
Thanks, 
Kevin D. Butt
SCSI & Fibre Channel Architect, Tape Firmware
MS 6TYA, 9000 S. Rita Rd., Tucson, AZ 85744
Tel: 520-799-2869 / 520-799-5280
Fax: 520-799-2723 (T/L:321)
Email address: kdbutt at us.ibm.com
http://www-03.ibm.com/servers/storage/ 
"Roger Cummings" <roger_cummings at symantec.com> 
Sent by: owner-t10 at t10.org 
12/14/2007 12:10 PM 
To
Kevin D Butt/Tucson/IBM at IBMUS 
cc
<t10 at t10.org> 
Subject
RE: Persistent Reservation Proposal - Group Reservations
Kevin, 
First of all, let me say that I completely support what you're trying to 
do here. I think that providing a method in persistent reservations (PRs) 
to support shared access between ONLY a specifically-designated set of 
systems is a worthy goal, and something we should do in SPC-4. 
Adding a set of Transport IDs to Reserve as per your document 08-024 & 
08-025 is certainly possible, but it's a massive change to the way that 
PRs work today, and it throws up a bunch of nasty corner cases and 
backwards compatibility issues. 
The massive change comes from the fact that now the Target will have to 
remember which registrations are in the Reservation, and which are not. It 
will probably have to preserve all of the transport information for the 
life of the reservation. 
The corner cases are things like, what happens if there's no longer a 
registration that corresponds to the transport ID in the Reserve? Does the 
Reserve succeed? What happens if a registration comes in later, after the 
reservation has been established - does that device it get access? 
Backwards compatibility issues may arise like this: An existing device 
registers, and finds it has no access, so it does a PR In and finds out 
that a reservation is in place, retries its access and still it has no 
access. What does it do next, preempt the reservation because it assumes 
the Target is broken? 
Reserve also has to be an "atomic" command, and I've always thought that 
was why it's functionality is as compact as it is today. Most of the 
complex operations related to addresses and keys are done at registration 
time, and those operations don't have to be atomic. 
One more thing: you chose for your new "group" reservations to follow the 
"all registrants" approach is terms of the definition of the reservation 
holder. While that's fine by me (obviously), I suspect there are also 
situations where group reservations that follow the "registrants only" 
approach might be useful. 
The bottom line from my point of view is this: Your proposal is feasible 
and we can probably make it work. But I wonder if there's an easier way to 
achieve the same goal that is more compatible with existing practice and 
requires less of a change in functionality on the Target side. 
What if we didn't add any new reservations types, but instead added some 
new functionality to the registration process? What I'm thinking of a new 
Register feature that causes the Target to kill all existing 
registrations, create the registrations identified in the transport IDs in 
the Register command, and not accept any future registrations. That way, 
we don't need any changes to Reserve, and an Initiator with existing 
functionality would just not be able to register and therefore would not 
be confused. 
Does that make sense to you? Is there a chance this is an easier approach? 
If so, I'll write up a detailed proposal that's the equivalent of 08-025r0 
and we can compare and contrast at the next CAP. 
Again, thanks for getting this started, I think it's a worthwhile endeavor 
and I'll be glad to put some cycles towards defining this sort of 
functionality for SPC-4. 
Regards, 
Roger 
From: owner-t10 at t10.org [mailto:owner-t10 at t10.org] On Behalf Of Kevin D 
Butt
Sent: Monday, December 10, 2007 4:18 PM
To: t10 at t10.org
Subject: Persistent Reservation Proposal - Group Reservations
I have posted two documents related to an additional Persistent 
Reservation Type.  The first document is a presentation on where 
persistent reservations are today and where they fall short in the 
scenarios covered by the proposal.  It also covers the intent of the 
proposal and what will be proposed.  The second is the actual proposal 
Your PDF file will be posted at:
http://www.t10.org/ftp/t10/document.08/08-024r0.pdf 
 http://www.t10.org/ftp/t10/document.08/08-025r0.pdf
Normally, the posting/archiving process takes about 30 minutes. 
Kevin D. Butt
SCSI & Fibre Channel Architect, Tape Firmware, IBM
MS 6TYA, 9000 S. Rita Rd., Tucson, AZ 85744
Tel: 520-799-2869 / 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 kdbutt at us.ibm.com  Fri Dec 21 15:36:51 2007
From: kdbutt at us.ibm.com (Kevin D Butt)
Date: Fri, 21 Dec 2007 16:36:51 -0700
Subject: ADI - SMC tape alerts using ADI bridging (re proposal 06-420r2 and
    smc3r09)
Message-ID: <mailman.866.1441607324.22512.t10@sandbox.t10.org>

Formatted message: <A HREF="r0712213_f.htm">HTML-formatted message</A>

Geoff,
You are absolutely correct.
Kevin D. Butt
SCSI & Fibre Channel Architect, Tape Firmware
MS 6TYA, 9000 S. Rita Rd., Tucson, AZ 85744
Tel: 520-799-2869 / 520-799-5280
Fax: 520-799-2723 (T/L:321)
Email address: kdbutt at us.ibm.com
http://www-03.ibm.com/servers/storage/ 
GBarton at overlandstorage.com 
12/21/2007 04:06 PM
To
Kevin D Butt/Tucson/IBM at IBMUS, t10 at t10.org
cc
Subject
RE: ADI - SMC tape alerts using ADI bridging (re proposal 06-420r2 and 
smc3r09)
Kevin, 
I suspect you are right. However, that still leaves problem if a 
implementer wanted to respond on a per initiator basis, as the SMC 
standard requires: smc2 clause 5.5.2 lettered list a) "after the TapeAlert 
log page is read. The TapeAlert flags shall be deactivated on a per 
initiator 
basis such that active flags are available for other initiators;". The 
same statement is in smc3r09 and in proposal 06-420r2 clause 5.4.3 with 
the "shall" changed to "should" or "may" depending on the state of the 
TAPLSD bit. 
Geoffrey L. Barton
Overland Storage
4820 Overland Ave.
San Diego, CA 92123
858 974-4586
gbarton at overlandstorage.com 
Kevin D Butt <kdbutt at us.ibm.com> 
Sent by: owner-t10 at t10.org 
12/19/2007 06:58 PM 
To
"Rose, Roger" <Rrose at tandbergdata.com> 
cc
GBarton at overlandstorage.com, owner-t10 at t10.org, t10 at t10.org 
Subject
RE: ADI - SMC tape alerts using ADI bridging (re proposal 06-420r2 and 
smc3r09)
I suspect that all implementers have only one set of SMC tapealerts and 
that they get cleared when the first initiator reads them.  I have not 
checked our implementation, but this is my guess since there is no way to 
communicate I_T nexus to the SMC device. 
Kevin D. Butt
SCSI & Fibre Channel Architect, Tape Firmware
MS 6TYA, 9000 S. Rita Rd., Tucson, AZ 85744
Tel: 520-799-2869 / 520-799-5280
Fax: 520-799-2723 (T/L:321)
Email address: kdbutt at us.ibm.com
http://www-03.ibm.com/servers/storage/ 
"Rose, Roger" <Rrose at tandbergdata.com> 
Sent by: owner-t10 at t10.org 
12/19/2007 05:00 PM 
To
<t10 at t10.org>, <GBarton at overlandstorage.com> 
cc
Subject
RE: ADI - SMC tape alerts using ADI bridging (re proposal 06-420r2 and 
smc3r09)
Geoffrey, 
I suppose I may be confused on which set of tape alerts.  (I tend to be 
confused fairly easily.) 
I haven't run tests on this either, but I doubt whether any ADI Bridge 
drives cache the Library Log Sense data to allow per-initiator clearing. 
There currently isn't any obvious mechanism to indicate that the Log Sense 
data has changed and the cache needs refreshed.   
The technique you've described to pass the command through and update the 
cache might be workable.  It appears to have an odd corner case: 
If the Remote SMC Device Server clears Tape Alert bits upon sending them 
to the bridge, then upon the next retrieval the bridge won't be able to 
tell whether (a) the bits are still cleared from the last retrieval or (b) 
the underlying condition has been cleared (e.g. by performing the 
specified corrective action) and shouldn't be reported to other initiators 
anymore. 
If the Remote SMC Device Server doesn't clear Tape Alert bits upon sending 
them to the bridge, then upon the next retrieval the bridge won't be able 
to tell whether (a) the condition persists and should not be reported 
again to initiators that have already seen it or (b) the underlying 
condition was cleared and has actually occurred again. 
I suspect that supporting per-initiator Tape Alert would require adding 
another flag to Notify data Transfer Device or something along those 
lines.	 
-roger rose 
Product Test, Tandberg Data 
From: GBarton at overlandstorage.com [mailto:GBarton at overlandstorage.com] 
Sent: Wednesday, December 19, 2007 3:57 PM
To: t10 at t10.org
Cc: Rose, Roger
Subject: RE: ADI - SMC tape alerts using ADI bridging (re proposal 
06-420r2 and smc3r09)
roger, 
I think what you are talking about is the TapeAlert for the DT device 
(tape drive) as specified in ssc2 that the library can use to track and/or 
report problems in it's tape drives. I am talking about the library 
TapAlerts defined in smc2 and currently smc3 and referred to in proposal 
06-420r2. Currently, log page 12h TapeAlert Response Log Page is not 
currently specified in smc2 or smc3. Rather, log page 2Eh TapeAlert Log 
Page. If the host access to the library is through the ADI bridge, the 
host (or hosts) can request log page 2Eh. There is currently no mechanism 
using ADI bridging to clear the flags at the library on a per I-T nexus 
basis, since the library has no visibility of the initiator. The DT device 
(tape drive) can keep track of which initiators have requested page 2Eh, 
but there is no mechanism to keep the tape drive up to date on current 
tape alerts set, unless the DT device passes the log sense command through 
the bridge (which will clear the flags in the library) and intercepts the 
log page and updates cached values accordingly. Is this being done by tape 
drives? I have not run an experiment to find out. 
Geoffrey L. Barton
Overland Storage
4820 Overland Ave.
San Diego, CA 92123
858 974-4586
gbarton at overlandstorage.com 
"Rose, Roger" <Rrose at tandbergdata.com> 
12/19/2007 02:21 PM 
To
<GBarton at overlandstorage.com>, <t10 at t10.org> 
cc
Subject
RE: ADI - SMC tape alerts using ADI bridging (re proposal 06-420r2 and 
smc3r09)
This is currently covered by ADC section 4.2.6 and ADC-2 Rev 8 section 
4.6. 
>From ADC-2: 
4.6 TapeAlert application client interface 
The ADC device server supports a modified version of TapeAlert specified 
in SSC-2. As supported by the ADC device server, the TapeAlert flags 
represent states, and the state flags are not set to zero upon retrieval 
of the TapeAlert Response log page (see 6.1.3). Instead, the state flags 
are set to zero upon a change of the condition involved with the state 
(see table 5). 
-roger rose 
Product Test, Tandberg Data 
From: owner-t10 at t10.org [mailto:owner-t10 at t10.org] On Behalf Of 
GBarton at overlandstorage.com
Sent: Tuesday, December 18, 2007 3:07 PM
To: curtis.ballard at hp.com; michael_banther at hp.com; kdbutt at us.ibm.com; 
halvard.eriksen at tandbergstorage.com; PayneR at iomega.com; 
Paul.Stone at Quantum.com; paul.suhler at Quantum.com
Cc: t10 at t10.org
Subject: ADI - SMC tape alerts using ADI bridging (re proposal 06-420r2 
and smc3r09)
In reviewing Michael Banther's proposal for tape alert flag (06-420r2), it 
occurred to me that there is a problem with SMC tape alerts in general if 
ADI bridging is being used for host access to the library. 
smc3r09 clause 5.2.2 third paragraph defines deactivations for tape 
alerts. Numbered list 1) states "after the TapeAlert log page is read. The 
TapeAlert flags shall be deactivated on a per-initiator basis such that 
active flags are available for other initiators; ".   
and in proposal 06-420r2 clause 5.4.4 last paragraph, the same statement 
is made with "should" instead of "shall". 
Since a library device using ADI bridging is not aware of initiators, the 
library cannot clear the flags on a per initiator basis. Does this mean 
the DT device must cache the tape alert log page and keep track of the 
reads of that log page? If so, how does the DT device know when to cache a 
new page? And if the DT device handles the tape alert log page on a per 
initiator basis, how does the library know when to clear the flags? As far 
as I can tell, there is no mechanism to handle this. 
Even if proposal 06-420r2 is not incorporated into smc3, the problem still 
exists. 
regards, 
Geoffrey L. Barton
Overland Storage
----------------------------------------------------
Tiered Data Protection Made Simple
http://www.overlandstorage.com/
---------------------------------------------------- 


From raymond_gilson at symantec.com  Sat Dec 22 06:06:46 2007
From: raymond_gilson at symantec.com (Raymond Gilson)
Date: Sat, 22 Dec 2007 07:06:46 -0700
Subject: Persistent Reservation Proposal - Group Reservations
Message-ID: <mailman.867.1441607324.22512.t10@sandbox.t10.org>

Formatted message: <A HREF="r0712220_f.htm">HTML-formatted message</A>

Comments in line
________________________________
From: Kevin D Butt [mailto:kdbutt at us.ibm.com] 
Sent: Friday, December 21, 2007 5:33 PM
To: Raymond Gilson
Cc: Christine R Knibloe; Knight, Frederick; Roger Cummings; t10 at t10.org
Subject: RE: Persistent Reservation Proposal - Group Reservations
Ray, 
Thanks for joining in.	Let me summarize what I think has been said by
all parties who have joined in these discussions. 
1) (From Ray) Some applications will have trouble providing a list of
Transport IDs. 
2) (From Fred) There is a desire to allow members of a cluster that were
not active at the creation of the reservation to join in. 
3) (From Kevin) Who can join or participate in a group reservation is
required to be controlled such that only those initiators that are part
of the cluster (i.e. group) can join. 
4) PREEMPT must be allowed (i.e., what we do cannot lock out PREEMPT or
make it not work correctly) 
5) Both Registrants Only and All Registrants types of functionality need
to be provided for. 
6) There should be an option for all target ports 
If we can't require a list of Transport ID's then it seems that the
suggested "shared secret" (not cryptographic, just some unique value
that is protected through obfuscation) is probably the best way to do
this.  This would be something akin to requiring the same reservation
key value.  However, using the reservation key does not seem to be
plausible because of how it is being used today.  What we need would be
some different value that would not be reportable via a Persistent
Reserve In.  This would keep third-party initiators from joining the
reservation.  If this new Group Reservation Identifier (GRID) were
added, that would take care of #1, #2, and #3 above. 
For #5 above, it seems that we could provide that by adding a bit in the
reserve command that indicates "All Participants are reservation
holders".  If set to one, then it acts like an All Registrants.  If set
to zero then it acts like Registrants Only.  This includes in the
unregistering. 
For #6 we use the ALL_TGT_PORTS bit the same as other reservations
today. 
Issues still to be resolved: 
a) Some systems won't want to require all initiators to send a
Persistent Reserve Out command.  Possible solution is to allow reserving
multiple initiators if a Transport ID list is sent.  Additional
initiators could join later if they have the GRID.  However this would
make it more complicated and if it is not needed I would rather not add
this option.  
In a practical sense, I cannot see how this could be avoided (all
initiators sending PRO) -- since PR requires trust and good behavior,
each initiator must make no assumption about what the protection level
is currently set at -- so it must verify the settings as the correct and
expected.  If the settings aren't as expected, it must bail out, or go
into error recovery to attempt to avoid messing up some other
application (a fist fight on the SAN for device control does nobody any
good).	I see no reason to provide for this (I do know that the current
command allows a registration for multiple ports, but I cannot imagine
using it in the real world). 
b) If the first I_T nexus sets the "All Participants are reservation
holders" to zero when it creates the reservation and then a subsequent
I_T nexus sets it to one, what is the behavior?  Change the type?
Reject?  Also, what is reported in the Report Full Status if All
Participants are reservation holders is set to zero?  
I don't think this is a problem -- once a reservation is established it
cannot be changed without a preempt, clear, or removal of the old.  If
this isn't either true, I would want the attempt to change it to get
rejected.  I would expect a change to require a preempt type operation.
c) If we go to this method of using the GRID to determine who can join,
then the Reservation Key may or may not be different. 
c-1) if the Reservation Key is different, then a PREEMPT of a
Reservation Key will do what? 
c-2) if the Reservation Key is the same, then a PREEMPT will act the
same as an AR or RO reservation today. 
c-3) Do we require the Reservation Key to be the same?	
Preempt is of a reservation, not a key.  The key's currently are not
compared, and have no valid use (by the device) except that each
initiator has registered one, and only one at a time.  We don't want to
change this behavior -- a key is random number assigned for some
external purpose that the device records and reports.  (My application
requires this to operate properly) 
d) Does this approach still have the issues that Roger was concerned
about (e.g., the corner cases)? 
 I hope the use of a GRID would not introduce any new issues to SPR --
it only prevents a registrant from becoming a reservation participant
without some external knowledge.  It doesn't prevent a registrant from
preempt, clear, or any other error recovery operations (and MUST not). 
Thanks, 
Kevin D. Butt
SCSI & Fibre Channel Architect, Tape Firmware
MS 6TYA, 9000 S. Rita Rd., Tucson, AZ 85744
Tel: 520-799-2869 / 520-799-5280
Fax: 520-799-2723 (T/L:321)
Email address: kdbutt at us.ibm.com
http://www-03.ibm.com/servers/storage/ 
"Raymond Gilson" <raymond_gilson at symantec.com> 
12/21/2007 12:45 PM 
To
"Roger Cummings" <roger_cummings at symantec.com>, "Knight, Frederick"
<Frederick.Knight at netapp.com>, Kevin D Butt/Tucson/IBM at IBMUS 
cc
<t10 at t10.org>, Christine R Knibloe/Tucson/IBM at IBMUS 
Subject
RE: Persistent Reservation Proposal - Group Reservations
Several years ago I was trying to figure out a way to introduce a "JOIN"
function to the SPR.  The initiator would register, but that would not
grant it access to a reservation of the "joined only" type.  To join it,
the initiator would have to send a join SPR command -- we could add a
"shared secret" field to the join, so that only those initiators that
knew the secret could join. 
I think we will have a great deal of trouble with a "white list"
approach -- as an application, I have no idea what my port ID is (or
anything else for that matter). 
Would something like this make sense? 
Thanks, 
Ray Gilson 
________________________________
From: owner-t10 at t10.org [mailto:owner-t10 at t10.org] On Behalf Of Roger
Cummings
Sent: Tuesday, December 18, 2007 10:24 AM
To: Knight, Frederick; Kevin D Butt
Cc: t10 at t10.org; Christine R Knibloe
Subject: RE: Persistent Reservation Proposal - Group Reservations
Fred, 
The way you clean up from a disaster is to Preempt, that's what it's
there for. Most of the applications that I know that will actually issue
a Preempt make it a very special function that doesn't happen in the
normal flow, and one app at least DOES require manual intervention of an
operator before kicking off the preempt. 
Yes, today, a Preempt has to be issued through a registered I_T nexus,
but a registration with the SPEC_I_T bit doesn't have to come from an
already registered initiator - see Table 33 in SPC-4, and I don't
believe Kevin changed that in his proposal. 
For the future, however we define a "group" for the purposes of new
reservation types, we will have to make sure that an Initiator outside
of the "group" can issue a Preempt to handle the disaster recovery case.
Regards, 
Roger 
________________________________
From: Knight, Frederick [mailto:Frederick.Knight at netapp.com] 
Sent: Tuesday, December 18, 2007 10:56 AM
To: Roger Cummings; Kevin D Butt
Cc: t10 at t10.org; Christine R Knibloe
Subject: RE: Persistent Reservation Proposal - Group Reservations
My question has had to do with differentiating the disaster clean up 
case from the non-cooperating host case. 
How do I clean up from a disaster?  If all my "reserved" initiators 
melt down, and there aren't any of them left anymore (because of 
a site disaster, or whatever), how does some other node come along 
and clean up so it can gain access? 
Would it require manual intervention?  Or, is there a way in the
protocol 
that I can register and preempt the group reservation (does the use 
of the SPEC_I_PT bit allow this as you have suggested Roger).  I 
thought the SPEC_I_PT had to come from an already registered 
initiator (which in a disaster, none exist anymore). 
    Fred Knight 
________________________________
From: Roger Cummings [mailto:roger_cummings at symantec.com] 
Sent: Tuesday, December 18, 2007 10:03 AM
To: Kevin D Butt; Knight, Frederick
Cc: t10 at t10.org; Christine R Knibloe
Subject: RE: Persistent Reservation Proposal - Group Reservations
Kevin, 
I'm sorry, I don't think it's as cut and dried as you make out. This
gets into some of the corner cases that I listed in my first response. 
The point to be made in response to Fred's case is that a third-party
can create registrations for a downed initiator (via the SPEC_I_PT) bit,
so that when it comes up again it will be able to participate in the
reservation without having to register itself. 
Also, you say that "We have made provisions for adding members once the
reservation exists, but only one of the reservation holders can add
another entity." Two things in response to that: 
1) I didn't see any specific provision for adding members in your
proposal, so I presume you'd just issue another RESERVE with the same
type and the whole list of transport IDs to be included again, and thus
the Target would have a whole lot of work to do again to set up another
reservation. 
2) I that really what you want, that an member of the existing group can
reissue the RESERVE with a whole bunch of different TransportIDs,
perhaps excluding some that were previously there? 
Regards, 
Roger 
________________________________
From: owner-t10 at t10.org [mailto:owner-t10 at t10.org] On Behalf Of Kevin D
Butt
Sent: Monday, December 17, 2007 3:54 PM
To: Knight, Frederick
Cc: t10 at t10.org; Christine R Knibloe
Subject: RE: Persistent Reservation Proposal - Group Reservations
Fred, 
This is being proposed for SPC. 
There are multiple types of reservations.  In an environment where one
node of a cluster must join later, one of the other types can be used.
Either that or have an existing node in your cluster add the new node.
The whole intent of this Group reservation is to lock out everybody that
is not explicitly specified during the reserve.  We have made provisions
for adding members once the reservation exists, but only one of the
reservation holders can add another entity.  The new entity cannot add
itself.  This is the whole point of reservations (i.e., lock out others
|from doing stuff while I think I have exclusive rights). 
To put it in other word's, to allow somebody to join the reservation of
their own accord without permission is EXACTLY what I am trying to
protect against. 
Thanks, 
Kevin D. Butt
SCSI & Fibre Channel Architect, Tape Firmware
MS 6TYA, 9000 S. Rita Rd., Tucson, AZ 85744
Tel: 520-799-2869 / 520-799-5280
Fax: 520-799-2723 (T/L:321)
Email address: kdbutt at us.ibm.com
http://www-03.ibm.com/servers/storage/ 
"Knight, Frederick" <Frederick.Knight at netapp.com> 
12/17/2007 01:38 PM 
To
Kevin D Butt/Tucson/IBM at IBMUS 
cc
Subject
RE: Persistent Reservation Proposal - Group Reservations
Sorry, you can't require everyone to register before the reserve. 
That's like saying my whole cluster can't boot because 1 node is down.
You need 
to have a way for a "down" initiator to join the fun after the fact. 
I helped write a host cluster product that used a shared tape (failover
model).  The 
backup application would write to the tape.  If a system failure ever
happened, the 
backup application would failover to a different host.	It would skip
backwards on 
the tape for a few records, recognize where it left off, and then resume
operation. 
BUT, for some protection, we used reservations to make sure only 1
initiator at a 
time could access the tape.  The interesting point however, is that we
were in the 
process of upgrading from old SCSI-2 RESERVE to using PR.  Because, we
also 
have multiple HBAs in the host, and we wanted to be able to use more
than 1 of 
those HBAs (so we needed multiple reservations - aka PR).  Having this
idea 
(group reservations) would have been a real nice addition. 
As for the RA/AR differences.  It seemed to be timing.	Registrants Only
was fairly 
early on (as I remember), and so implemented by several O/S vendors.
Later on, 
some issues were found (which got complicated spec-ees added to
address), but also, 
the All Registrants was added (which didn't have those issues).  But,
since there were 
implementations, it couldn't be removed like the other old PR types that
no one ever 
used.  Anyway, I agree, they offer basically the same capabilities, but
RO is already 
out there, and AR is probably what new implementers are using (it's
easier to understand 
and implement from the host side).  Most of the differences are already
documented, 
so there wouldn't be that much extra for you to write to have both types
(which I think 
would be better than bit somewhere - do it the same way all the others
are done).  But, 
you could also just do the AR version, and let someone else add the RO
version if they 
want it. 
Are you proposing this for tape only? or SPC in general?  I assume SPC
in general. 
   Fred Knight 
________________________________
From: Kevin D Butt [mailto:kdbutt at us.ibm.com] 
Sent: Monday, December 17, 2007 9:51 AM
To: Roger Cummings
Cc: t10 at t10.org
Subject: RE: Persistent Reservation Proposal - Group Reservations
Roger, 
Thank you for your feedback.  I am certainly willing to entertain  other
methods for accomplishing the end goal in an easier fashion.  I am not
sure I understand how your proposed method makes it more backward
compatible.  In my proposal PRin would show a different type of
reservation and hence the application clients would not try to join the
reservation because they don't know about the type.  In your proposal,
application clients would not be allowed to register.  This is a
deviation from what they can always do today - unless there is a
resource issue.  This seems more disruptive to me.  I would assume that
there would be a new additional sense code added for UNABLE TO REGISTER
BECAUSE A GROUP RESERVATION IS IN PLACE (or analogous).  This would be a
new thing for failure to register and there would be pain at the
register point.  Perhaps that is better than at the reserve point - but
I would think that it would be better handled as a reservation conflict
since that is what it is instead of something the application client
does not understand. 
As for "all registrants" type vs. "registrants only" I didn't see where
the difference would be interesting, but I am not opposed to providing a
way to switch between which of these two types is done.  Whether it is
additional types or some bit during registration etc. 
As for some of the corner cases mentioned below, if each I_T nexus that
is supposed to be part of the group reservation is required to be
registered before the reservation is made, and if the reservation is
released when the last group reservation participant is unregistered,
then I think we don't have an issue. 
I would prefer that we work together to shape a mutually beneficial
proposal as opposed to have "competing" proposals.  I am willing to
modify my proposal where it can be made easier and such.  I am not sold
that my proposed method is the only way or even the best - it's just the
way I thought of doing it.  I admit that I have always been very
confused about the usefulness of RA and AR types.  They make absolutely
no sense in the tape world. 
Thanks, 
Kevin D. Butt
SCSI & Fibre Channel Architect, Tape Firmware
MS 6TYA, 9000 S. Rita Rd., Tucson, AZ 85744
Tel: 520-799-2869 / 520-799-5280
Fax: 520-799-2723 (T/L:321)
Email address: kdbutt at us.ibm.com
http://www-03.ibm.com/servers/storage/ 
"Roger Cummings" <roger_cummings at symantec.com> 
Sent by: owner-t10 at t10.org 
12/14/2007 12:10 PM 
To
Kevin D Butt/Tucson/IBM at IBMUS 
cc
<t10 at t10.org> 
Subject
RE: Persistent Reservation Proposal - Group Reservations
Kevin, 
First of all, let me say that I completely support what you're trying to
do here. I think that providing a method in persistent reservations
(PRs) to support shared access between ONLY a specifically-designated
set of systems is a worthy goal, and something we should do in SPC-4. 
Adding a set of Transport IDs to Reserve as per your document 08-024 &
08-025 is certainly possible, but it's a massive change to the way that
PRs work today, and it throws up a bunch of nasty corner cases and
backwards compatibility issues. 
The massive change comes from the fact that now the Target will have to
remember which registrations are in the Reservation, and which are not.
It will probably have to preserve all of the transport information for
the life of the reservation. 
The corner cases are things like, what happens if there's no longer a
registration that corresponds to the transport ID in the Reserve? Does
the Reserve succeed? What happens if a registration comes in later,
after the reservation has been established - does that device it get
access? 
Backwards compatibility issues may arise like this: An existing device
registers, and finds it has no access, so it does a PR In and finds out
that a reservation is in place, retries its access and still it has no
access. What does it do next, preempt the reservation because it assumes
the Target is broken? 
Reserve also has to be an "atomic" command, and I've always thought that
was why it's functionality is as compact as it is today. Most of the
complex operations related to addresses and keys are done at
registration time, and those operations don't have to be atomic. 
One more thing: you chose for your new "group" reservations to follow
the "all registrants" approach is terms of the definition of the
reservation holder. While that's fine by me (obviously), I suspect there
are also situations where group reservations that follow the
"registrants only" approach might be useful. 
The bottom line from my point of view is this: Your proposal is feasible
and we can probably make it work. But I wonder if there's an easier way
to achieve the same goal that is more compatible with existing practice
and requires less of a change in functionality on the Target side. 
What if we didn't add any new reservations types, but instead added some
new functionality to the registration process? What I'm thinking of a
new Register feature that causes the Target to kill all existing
registrations, create the registrations identified in the transport IDs
in the Register command, and not accept any future registrations. That
way, we don't need any changes to Reserve, and an Initiator with
existing functionality would just not be able to register and therefore
would not be confused. 
Does that make sense to you? Is there a chance this is an easier
approach? If so, I'll write up a detailed proposal that's the equivalent
of 08-025r0 and we can compare and contrast at the next CAP. 
Again, thanks for getting this started, I think it's a worthwhile
endeavor and I'll be glad to put some cycles towards defining this sort
of functionality for SPC-4. 
Regards, 
Roger 
________________________________
From: owner-t10 at t10.org [mailto:owner-t10 at t10.org] On Behalf Of Kevin D
Butt
Sent: Monday, December 10, 2007 4:18 PM
To: t10 at t10.org
Subject: Persistent Reservation Proposal - Group Reservations
I have posted two documents related to an additional Persistent
Reservation Type.  The first document is a presentation on where
persistent reservations are today and where they fall short in the
scenarios covered by the proposal.  It also covers the intent of the
proposal and what will be proposed.  The second is the actual proposal 
Your PDF file will be posted at:
http://www.t10.org/ftp/t10/document.08/08-024r0.pdf 
http://www.t10.org/ftp/t10/document.08/08-025r0.pdf
Normally, the posting/archiving process takes about 30 minutes. 
Kevin D. Butt
SCSI & Fibre Channel Architect, Tape Firmware, IBM
MS 6TYA, 9000 S. Rita Rd., Tucson, AZ 85744
Tel: 520-799-2869 / 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 lohmeyer at t10.org  Sat Dec 22 23:00:36 2007
From: lohmeyer at t10.org (T10 Document Administrator)
Date: Sun, 23 Dec 2007 00:00:36 -0700
Subject: Recent T10 documents uploaded since 2007/12/16
Message-ID: <mailman.868.1441607324.22512.t10@sandbox.t10.org>

* From the T10 Reflector (t10 at t10.org), posted by:
* T10 Document Administrator <lohmeyer at t10.org>
*
Proposals
---------
ESP-SCSI for Parameter Data
(by: Ralph O. Weber)
T10/07-169r5   Uploaded: 2007/12/18   100462 bytes
ftp://ftp.t10.org/t10/document.07/07-169r5.pdf
SAS-2 6Gbps PHY specification
(by: Alvin Cox)
T10/07-339r8   Uploaded: 2007/12/20   1554840 bytes
ftp://ftp.t10.org/t10/document.07/07-339r8.pdf
SAS-2: Remove restrictions for SSC
(by: Gerald Houlder, Alvin Cox)
T10/08-014r1   Uploaded: 2007/12/19   38838 bytes
ftp://ftp.t10.org/t10/document.08/08-014r1.pdf
SAS-2: Remove restrictions for SSC
(by: Gerald Houlder, Alvin Cox)
T10/08-014r2   Uploaded: 2007/12/20   38880 bytes
ftp://ftp.t10.org/t10/document.08/08-014r2.pdf
Toward SSC Modulation Specs and Link Budget
(by: Guillaume Fortin, Rick Hernandez)
T10/08-027r2   Uploaded: 2007/12/20   1074855 bytes
ftp://ftp.t10.org/t10/document.08/08-027r2.pdf
Toward SSC Modulation Specs and Link Budget
(by: Guillaume Fortin, Mathieu Gagnon, Rick Hernandez)
T10/08-027r3   Uploaded: 2007/12/20   1074217 bytes
ftp://ftp.t10.org/t10/document.08/08-027r3.pdf
Minutes of SAS PHY Working Group conference call December 13, 2007
(by: Alvin Cox)
T10/08-028r0   Uploaded: 2007/12/17   23148 bytes
ftp://ftp.t10.org/t10/document.08/08-028r0.pdf
Proposed modifications to SSC profile definition
(by: Guillaume Fortin)
T10/08-032r0   Uploaded: 2007/12/20   8062 bytes
ftp://ftp.t10.org/t10/document.08/08-032r0.pdf
Considerations for Active Copper Cables for SAS
(by: Gourgen Oganessyan)
T10/08-033r0   Uploaded: 2007/12/20   1289005 bytes
ftp://ftp.t10.org/t10/document.08/08-033r0.pdf
Considerations for Active Copper Cables for SAS
(by: Gourgen Oganessyan)
T10/08-033r0   Uploaded: 2007/12/20   4890624 bytes
ftp://ftp.t10.org/t10/document.08/08-033r0.ppt
Error history cleanup
(by: Ralph O. Weber)
T10/08-034r0   Uploaded: 2007/12/19   58839 bytes
ftp://ftp.t10.org/t10/document.08/08-034r0.pdf
CbCS - Comments on 07-454r3 SMC3 permissions
(by: Rod Wideman)
T10/08-035r0   Uploaded: 2007/12/19   58987 bytes
ftp://ftp.t10.org/t10/document.08/08-035r0.pdf
Minutes of SAS PHY Working Group conference call December 20, 2007
(by: Alvin Cox)
T10/08-036r0   Uploaded: 2007/12/20   23109 bytes
ftp://ftp.t10.org/t10/document.08/08-036r0.pdf
Working Drafts
--------------
(Report generated on 2007/12/23 at 00:00:36)
*
* For T10 Reflector information, send a message with
* 'info t10' (no quotes) in the message body to majordomo at t10.org


From kdbutt at us.ibm.com  Mon Dec 24 07:39:34 2007
From: kdbutt at us.ibm.com (Kevin D Butt)
Date: Mon, 24 Dec 2007 08:39:34 -0700
Subject: Persistent Reservation Proposal - Group Reservations
Message-ID: <mailman.869.1441607324.22512.t10@sandbox.t10.org>

Attachment #1: <A HREF="r0712240_nameless-772-2-1.html">nameless-772-2-1.html</A>

Ray,
Please see this font.
Kevin D. Butt
SCSI & Fibre Channel Architect, Tape Firmware
MS 6TYA, 9000 S. Rita Rd., Tucson, AZ 85744
Tel: 520-799-2869 / 520-799-5280
Fax: 520-799-2723 (T/L:321)
Email address: kdbutt at us.ibm.com
http://www-03.ibm.com/servers/storage/ 
"Raymond Gilson" <raymond_gilson at symantec.com> 
12/22/2007 07:06 AM
To
Kevin D Butt/Tucson/IBM at IBMUS
cc
Christine R Knibloe/Tucson/IBM at IBMUS, "Knight, Frederick" 
<Frederick.Knight at netapp.com>, "Roger Cummings" 
<roger_cummings at symantec.com>, <t10 at t10.org>
Subject
RE: Persistent Reservation Proposal - Group Reservations
Comments in line
From: Kevin D Butt [mailto:kdbutt at us.ibm.com] 
Sent: Friday, December 21, 2007 5:33 PM
To: Raymond Gilson
Cc: Christine R Knibloe; Knight, Frederick; Roger Cummings; t10 at t10.org
Subject: RE: Persistent Reservation Proposal - Group Reservations
Ray, 
Thanks for joining in.	Let me summarize what I think has been said by all 
parties who have joined in these discussions. 
1) (From Ray) Some applications will have trouble providing a list of 
Transport IDs. 
2) (From Fred) There is a desire to allow members of a cluster that were 
not active at the creation of the reservation to join in. 
3) (From Kevin) Who can join or participate in a group reservation is 
required to be controlled such that only those initiators that are part of 
the cluster (i.e. group) can join. 
4) PREEMPT must be allowed (i.e., what we do cannot lock out PREEMPT or 
make it not work correctly) 
5) Both Registrants Only and All Registrants types of functionality need 
to be provided for. 
6) There should be an option for all target ports 
If we can't require a list of Transport ID's then it seems that the 
suggested "shared secret" (not cryptographic, just some unique value that 
is protected through obfuscation) is probably the best way to do this. 
This would be something akin to requiring the same reservation key value. 
However, using the reservation key does not seem to be plausible because 
of how it is being used today.	What we need would be some different value 
that would not be reportable via a Persistent Reserve In.  This would keep 
third-party initiators from joining the reservation.  If this new Group 
Reservation Identifier (GRID) were added, that would take care of #1, #2, 
and #3 above. 
For #5 above, it seems that we could provide that by adding a bit in the 
reserve command that indicates "All Participants are reservation holders". 
 If set to one, then it acts like an All Registrants.  If set to zero then 
it acts like Registrants Only.	This includes in the unregistering. 
For #6 we use the ALL_TGT_PORTS bit the same as other reservations today. 
Issues still to be resolved: 
a) Some systems won't want to require all initiators to send a Persistent 
Reserve Out command.  Possible solution is to allow reserving multiple 
initiators if a Transport ID list is sent.  Additional initiators could 
join later if they have the GRID.  However this would make it more 
complicated and if it is not needed I would rather not add this option.  
In a practical sense, I cannot see how this could be avoided (all 
initiators sending PRO) -- since PR requires trust and good behavior, each 
initiator must make no assumption about what the protection level is 
currently set at -- so it must verify the settings as the correct and 
expected.  If the settings aren't as expected, it must bail out, or go 
into error recovery to attempt to avoid messing up some other application 
(a fist fight on the SAN for device control does nobody any good).  I see 
no reason to provide for this (I do know that the current command allows a 
registration for multiple ports, but I cannot imagine using it in the real 
world). 
<<kdbutt: I am certainly willing to agree.  All could still be registered 
by using the all_i_pt bit. However, I suspect there will be those that 
will find this unacceptable.  Anybody who needs a way to add all 
initiators who are currently registered to the group reservation, please 
speak up (and comment on a method to accomplish this).>>
b) If the first I_T nexus sets the "All Participants are reservation 
holders" to zero when it creates the reservation and then a subsequent I_T 
nexus sets it to one, what is the behavior?  Change the type?  Reject? 
Also, what is reported in the Report Full Status if All Participants are 
reservation holders is set to zero?  
I don't think this is a problem -- once a reservation is established it 
cannot be changed without a preempt, clear, or removal of the old.  If 
this isn't either true, I would want the attempt to change it to get 
rejected.  I would expect a change to require a preempt type operation. 
<<kdbutt: I think the correct response for a new participant that attempts 
to change the type is to reject a command that attempts to change the 
type.
For what to return in Report Full Status if  "All Participants are 
reservation holders" is set to zero, I am concerned about confusion.  In 
reality, only the first is a reservation holder and therefore only the 
first should set the reservation_holder bit to one.  However, there would 
now be two groups that cannot be distinguished.  There first is not the 
reservation_holder but part of the reservation and the second is not the 
reservation_holder and not part of the reservation.  I think we should 
probably add a "group reservation participant" bit to distinguish the 
two.>>
c) If we go to this method of using the GRID to determine who can join, 
then the Reservation Key may or may not be different. 
c-1) if the Reservation Key is different, then a PREEMPT of a Reservation 
Key will do what? 
c-2) if the Reservation Key is the same, then a PREEMPT will act the same 
as an AR or RO reservation today. 
c-3) Do we require the Reservation Key to be the same?	
Preempt is of a reservation, not a key.  The key's currently are not 
compared, and have no valid use (by the device) except that each initiator 
has registered one, and only one at a time.  We don't want to change this 
behavior -- a key is random number assigned for some external purpose that 
the device records and reports.  (My application requires this to operate 
properly) 
<<kdbutt: Look at clause 5.6.10.4 of SPC-4r11.	This looks to me like the 
Reservation Key is used to decide between unregistering I_T nexuses with 
the sent reservation key or if the reservation key is that of the 
reservation holder, then removing the reservation and registrations of all 
that have that reservation key.  My intent is not to change the current 
behavior.>>
d) Does this approach still have the issues that Roger was concerned about 
(e.g., the corner cases)? 
 I hope the use of a GRID would not introduce any new issues to SPR -- it 
only prevents a registrant from becoming a reservation participant without 
some external knowledge.  It doesn't prevent a registrant from preempt, 
clear, or any other error recovery operations (and MUST not). 
Thanks, 
Kevin D. Butt
SCSI & Fibre Channel Architect, Tape Firmware
MS 6TYA, 9000 S. Rita Rd., Tucson, AZ 85744
Tel: 520-799-2869 / 520-799-5280
Fax: 520-799-2723 (T/L:321)
Email address: kdbutt at us.ibm.com
http://www-03.ibm.com/servers/storage/ 
"Raymond Gilson" <raymond_gilson at symantec.com> 
12/21/2007 12:45 PM 
To
"Roger Cummings" <roger_cummings at symantec.com>, "Knight, Frederick" 
<Frederick.Knight at netapp.com>, Kevin D Butt/Tucson/IBM at IBMUS 
cc
<t10 at t10.org>, Christine R Knibloe/Tucson/IBM at IBMUS 
Subject
RE: Persistent Reservation Proposal - Group Reservations
Several years ago I was trying to figure out a way to introduce a "JOIN" 
function to the SPR.  The initiator would register, but that would not 
grant it access to a reservation of the "joined only" type.  To join it, 
the initiator would have to send a join SPR command -- we could add a 
"shared secret" field to the join, so that only those initiators that knew 
the secret could join. 
I think we will have a great deal of trouble with a "white list" approach 
-- as an application, I have no idea what my port ID is (or anything else 
for that matter). 
Would something like this make sense? 
Thanks, 
Ray Gilson 
From: owner-t10 at t10.org [mailto:owner-t10 at t10.org] On Behalf Of Roger 
Cummings
Sent: Tuesday, December 18, 2007 10:24 AM
To: Knight, Frederick; Kevin D Butt
Cc: t10 at t10.org; Christine R Knibloe
Subject: RE: Persistent Reservation Proposal - Group Reservations
Fred, 
The way you clean up from a disaster is to Preempt, that's what it's there 
for. Most of the applications that I know that will actually issue a 
Preempt make it a very special function that doesn't happen in the normal 
flow, and one app at least DOES require manual intervention of an operator 
before kicking off the preempt. 
Yes, today, a Preempt has to be issued through a registered I_T nexus, but 
a registration with the SPEC_I_T bit doesn't have to come from an already 
registered initiator - see Table 33 in SPC-4, and I don't believe Kevin 
changed that in his proposal. 
For the future, however we define a "group" for the purposes of new 
reservation types, we will have to make sure that an Initiator outside of 
the "group" can issue a Preempt to handle the disaster recovery case. 
Regards, 
Roger 
From: Knight, Frederick [mailto:Frederick.Knight at netapp.com] 
Sent: Tuesday, December 18, 2007 10:56 AM
To: Roger Cummings; Kevin D Butt
Cc: t10 at t10.org; Christine R Knibloe
Subject: RE: Persistent Reservation Proposal - Group Reservations
My question has had to do with differentiating the disaster clean up 
case from the non-cooperating host case. 
How do I clean up from a disaster?  If all my "reserved" initiators 
melt down, and there aren't any of them left anymore (because of 
a site disaster, or whatever), how does some other node come along 
and clean up so it can gain access? 
Would it require manual intervention?  Or, is there a way in the protocol 
that I can register and preempt the group reservation (does the use 
of the SPEC_I_PT bit allow this as you have suggested Roger).  I 
thought the SPEC_I_PT had to come from an already registered 
initiator (which in a disaster, none exist anymore). 
    Fred Knight 
From: Roger Cummings [mailto:roger_cummings at symantec.com] 
Sent: Tuesday, December 18, 2007 10:03 AM
To: Kevin D Butt; Knight, Frederick
Cc: t10 at t10.org; Christine R Knibloe
Subject: RE: Persistent Reservation Proposal - Group Reservations
Kevin, 
I'm sorry, I don't think it's as cut and dried as you make out. This gets 
into some of the corner cases that I listed in my first response. 
The point to be made in response to Fred's case is that a third-party can 
create registrations for a downed initiator (via the SPEC_I_PT) bit, so 
that when it comes up again it will be able to participate in the 
reservation without having to register itself. 
Also, you say that "We have made provisions for adding members once the 
reservation exists, but only one of the reservation holders can add 
another entity." Two things in response to that: 
1) I didn't see any specific provision for adding members in your 
proposal, so I presume you'd just issue another RESERVE with the same type 
and the whole list of transport IDs to be included again, and thus the 
Target would have a whole lot of work to do again to set up another 
reservation. 
2) I that really what you want, that an member of the existing group can 
reissue the RESERVE with a whole bunch of different TransportIDs, perhaps 
excluding some that were previously there? 
Regards, 
Roger 
From: owner-t10 at t10.org [mailto:owner-t10 at t10.org] On Behalf Of Kevin D 
Butt
Sent: Monday, December 17, 2007 3:54 PM
To: Knight, Frederick
Cc: t10 at t10.org; Christine R Knibloe
Subject: RE: Persistent Reservation Proposal - Group Reservations
Fred, 
This is being proposed for SPC. 
There are multiple types of reservations.  In an environment where one 
node of a cluster must join later, one of the other types can be used. 
Either that or have an existing node in your cluster add the new node. The 
whole intent of this Group reservation is to lock out everybody that is 
not explicitly specified during the reserve.  We have made provisions for 
adding members once the reservation exists, but only one of the 
reservation holders can add another entity.  The new entity cannot add 
itself.  This is the whole point of reservations (i.e., lock out others 
|from doing stuff while I think I have exclusive rights). 
To put it in other word's, to allow somebody to join the reservation of 
their own accord without permission is EXACTLY what I am trying to protect 
against. 
Thanks, 
Kevin D. Butt
SCSI & Fibre Channel Architect, Tape Firmware
MS 6TYA, 9000 S. Rita Rd., Tucson, AZ 85744
Tel: 520-799-2869 / 520-799-5280
Fax: 520-799-2723 (T/L:321)
Email address: kdbutt at us.ibm.com
http://www-03.ibm.com/servers/storage/ 
"Knight, Frederick" <Frederick.Knight at netapp.com> 
12/17/2007 01:38 PM 
To
Kevin D Butt/Tucson/IBM at IBMUS 
cc
Subject
RE: Persistent Reservation Proposal - Group Reservations
Sorry, you can't require everyone to register before the reserve. 
That's like saying my whole cluster can't boot because 1 node is down. You 
need 
to have a way for a "down" initiator to join the fun after the fact. 
I helped write a host cluster product that used a shared tape (failover 
model).  The 
backup application would write to the tape.  If a system failure ever 
happened, the 
backup application would failover to a different host.	It would skip 
backwards on 
the tape for a few records, recognize where it left off, and then resume 
operation. 
BUT, for some protection, we used reservations to make sure only 1 
initiator at a 
time could access the tape.  The interesting point however, is that we 
were in the 
process of upgrading from old SCSI-2 RESERVE to using PR.  Because, we 
also 
have multiple HBAs in the host, and we wanted to be able to use more than 
1 of 
those HBAs (so we needed multiple reservations - aka PR).  Having this 
idea 
(group reservations) would have been a real nice addition. 
As for the RA/AR differences.  It seemed to be timing.	Registrants Only 
was fairly 
early on (as I remember), and so implemented by several O/S vendors. Later 
on, 
some issues were found (which got complicated spec-ees added to address), 
but also, 
the All Registrants was added (which didn't have those issues).  But, 
since there were 
implementations, it couldn't be removed like the other old PR types that 
no one ever 
used.  Anyway, I agree, they offer basically the same capabilities, but RO 
is already 
out there, and AR is probably what new implementers are using (it's easier 
to understand 
and implement from the host side).  Most of the differences are already 
documented, 
so there wouldn't be that much extra for you to write to have both types 
(which I think 
would be better than bit somewhere - do it the same way all the others are 
done).	But, 
you could also just do the AR version, and let someone else add the RO 
version if they 
want it. 
Are you proposing this for tape only? or SPC in general?  I assume SPC in 
general. 
   Fred Knight 
From: Kevin D Butt [mailto:kdbutt at us.ibm.com] 
Sent: Monday, December 17, 2007 9:51 AM
To: Roger Cummings
Cc: t10 at t10.org
Subject: RE: Persistent Reservation Proposal - Group Reservations
Roger, 
Thank you for your feedback.  I am certainly willing to entertain  other 
methods for accomplishing the end goal in an easier fashion.  I am not 
sure I understand how your proposed method makes it more backward 
compatible.  In my proposal PRin would show a different type of 
reservation and hence the application clients would not try to join the 
reservation because they don't know about the type.  In your proposal, 
application clients would not be allowed to register.  This is a deviation 
|from what they can always do today - unless there is a resource issue. 
This seems more disruptive to me.  I would assume that there would be a 
new additional sense code added for UNABLE TO REGISTER BECAUSE A GROUP 
RESERVATION IS IN PLACE (or analogous).  This would be a new thing for 
failure to register and there would be pain at the register point. Perhaps 
that is better than at the reserve point - but I would think that it would 
be better handled as a reservation conflict since that is what it is 
instead of something the application client does not understand. 
As for "all registrants" type vs. "registrants only" I didn't see where 
the difference would be interesting, but I am not opposed to providing a 
way to switch between which of these two types is done.  Whether it is 
additional types or some bit during registration etc. 
As for some of the corner cases mentioned below, if each I_T nexus that is 
supposed to be part of the group reservation is required to be registered 
before the reservation is made, and if the reservation is released when 
the last group reservation participant is unregistered, then I think we 
don't have an issue. 
I would prefer that we work together to shape a mutually beneficial 
proposal as opposed to have "competing" proposals.  I am willing to modify 
my proposal where it can be made easier and such.  I am not sold that my 
proposed method is the only way or even the best - it's just the way I 
thought of doing it.  I admit that I have always been very confused about 
the usefulness of RA and AR types.  They make absolutely no sense in the 
tape world. 
Thanks, 
Kevin D. Butt
SCSI & Fibre Channel Architect, Tape Firmware
MS 6TYA, 9000 S. Rita Rd., Tucson, AZ 85744
Tel: 520-799-2869 / 520-799-5280
Fax: 520-799-2723 (T/L:321)
Email address: kdbutt at us.ibm.com
http://www-03.ibm.com/servers/storage/ 
"Roger Cummings" <roger_cummings at symantec.com> 
Sent by: owner-t10 at t10.org 
12/14/2007 12:10 PM 
To
Kevin D Butt/Tucson/IBM at IBMUS 
cc
<t10 at t10.org> 
Subject
RE: Persistent Reservation Proposal - Group Reservations
Kevin, 
First of all, let me say that I completely support what you're trying to 
do here. I think that providing a method in persistent reservations (PRs) 
to support shared access between ONLY a specifically-designated set of 
systems is a worthy goal, and something we should do in SPC-4. 
Adding a set of Transport IDs to Reserve as per your document 08-024 & 
08-025 is certainly possible, but it's a massive change to the way that 
PRs work today, and it throws up a bunch of nasty corner cases and 
backwards compatibility issues. 
The massive change comes from the fact that now the Target will have to 
remember which registrations are in the Reservation, and which are not. It 
will probably have to preserve all of the transport information for the 
life of the reservation. 
The corner cases are things like, what happens if there's no longer a 
registration that corresponds to the transport ID in the Reserve? Does the 
Reserve succeed? What happens if a registration comes in later, after the 
reservation has been established - does that device it get access? 
Backwards compatibility issues may arise like this: An existing device 
registers, and finds it has no access, so it does a PR In and finds out 
that a reservation is in place, retries its access and still it has no 
access. What does it do next, preempt the reservation because it assumes 
the Target is broken? 
Reserve also has to be an "atomic" command, and I've always thought that 
was why it's functionality is as compact as it is today. Most of the 
complex operations related to addresses and keys are done at registration 
time, and those operations don't have to be atomic. 
One more thing: you chose for your new "group" reservations to follow the 
"all registrants" approach is terms of the definition of the reservation 
holder. While that's fine by me (obviously), I suspect there are also 
situations where group reservations that follow the "registrants only" 
approach might be useful. 
The bottom line from my point of view is this: Your proposal is feasible 
and we can probably make it work. But I wonder if there's an easier way to 
achieve the same goal that is more compatible with existing practice and 
requires less of a change in functionality on the Target side. 
What if we didn't add any new reservations types, but instead added some 
new functionality to the registration process? What I'm thinking of a new 
Register feature that causes the Target to kill all existing 
registrations, create the registrations identified in the transport IDs in 
the Register command, and not accept any future registrations. That way, 
we don't need any changes to Reserve, and an Initiator with existing 
functionality would just not be able to register and therefore would not 
be confused. 
Does that make sense to you? Is there a chance this is an easier approach? 
If so, I'll write up a detailed proposal that's the equivalent of 08-025r0 
and we can compare and contrast at the next CAP. 
Again, thanks for getting this started, I think it's a worthwhile endeavor 
and I'll be glad to put some cycles towards defining this sort of 
functionality for SPC-4. 
Regards, 
Roger 
From: owner-t10 at t10.org [mailto:owner-t10 at t10.org] On Behalf Of Kevin D 
Butt
Sent: Monday, December 10, 2007 4:18 PM
To: t10 at t10.org
Subject: Persistent Reservation Proposal - Group Reservations
I have posted two documents related to an additional Persistent 
Reservation Type.  The first document is a presentation on where 
persistent reservations are today and where they fall short in the 
scenarios covered by the proposal.  It also covers the intent of the 
proposal and what will be proposed.  The second is the actual proposal 
Your PDF file will be posted at:
http://www.t10.org/ftp/t10/document.08/08-024r0.pdf 
http://www.t10.org/ftp/t10/document.08/08-025r0.pdf
Normally, the posting/archiving process takes about 30 minutes. 
Kevin D. Butt
SCSI & Fibre Channel Architect, Tape Firmware, IBM
MS 6TYA, 9000 S. Rita Rd., Tucson, AZ 85744
Tel: 520-799-2869 / 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 keiji_katata at post.pioneer.co.jp  Mon Dec 24 16:39:19 2007
From: keiji_katata at post.pioneer.co.jp (keiji_katata at post.pioneer.co.jp)
Date: Tue, 25 Dec 2007 09:39:19 +0900
Subject: 1/14 SWG meeting announcement at T10 place
Message-ID: <mailman.870.1441607324.22512.t10@sandbox.t10.org>

* From the T10 Reflector (t10 at t10.org), posted by:
* keiji_katata at post.pioneer.co.jp
*
Hello all,
Curtis Stevens of WDC kindly prepares a meeting room at Embassy Suites T10
place.
After our meeting STA will use the meeting room. Therefore we should end our
meeting at 4PM. So please take your lunch before meeting. We do not have a
lunch
break.
Agenda: Real-time streaming playback model
Date: 2008/1/14
Time: 12:00AM - 4:00PM
Place/Map:
 http://www.t10.org/meeting.htm
Best regards,
Keiji Katata
PIONEER CORP.
*
* For T10 Reflector information, send a message with
* 'info t10' (no quotes) in the message body to majordomo at t10.org


From keiji_katata at post.pioneer.co.jp  Mon Dec 24 17:23:22 2007
From: keiji_katata at post.pioneer.co.jp (keiji_katata at post.pioneer.co.jp)
Date: Tue, 25 Dec 2007 10:23:22 +0900
Subject: 1/14 SWG meeting announcement at T10 place
Message-ID: <mailman.871.1441607324.22512.t10@sandbox.t10.org>

* From the T10 Reflector (t10 at t10.org), posted by:
* keiji_katata at post.pioneer.co.jp
*
Sorry, SWG meeting will start from 12PM and will end at 4PM.
Best regards,
Keiji Katata
PIONEER CORP.
keiji_katata at post.pioneer.co.jp@avc-pioneer.com on 2007/12/25 09:39:19
mtfuji5 at avc-pioneer.com$B$KJV?.$7$F$/$@$5$$(B
$BAw?.<T(B:	  owner-mtfuji5 at avc-pioneer.com
$B08 at h(B:  mtfuji5 at avc-pioneer.com
cc:    T10 Reflector <t10 at t10.org>
bcc:
$B7oL>(B:  1/14 SWG meeting announcement at T10 place
Hello all,
Curtis Stevens of WDC kindly prepares a meeting room at Embassy Suites T10
place.
After our meeting STA will use the meeting room. Therefore we should end our
meeting at 4PM. So please take your lunch before meeting. We do not have a
lunch
break.
Agenda: Real-time streaming playback model
Date: 2008/1/14
Time: 12:00AM - 4:00PM
Place/Map:
 http://www.t10.org/meeting.htm
Best regards,
Keiji Katata
PIONEER CORP.
*
* For T10 Reflector information, send a message with
* 'info t10' (no quotes) in the message body to majordomo at t10.org


From keiji_katata at post.pioneer.co.jp  Tue Dec 25 17:50:12 2007
From: keiji_katata at post.pioneer.co.jp (keiji_katata at post.pioneer.co.jp)
Date: Wed, 26 Dec 2007 10:50:12 +0900
Subject: 1/9 SWG meeting Walking path
Message-ID: <mailman.872.1441607324.22512.t10@sandbox.t10.org>

* From the T10 Reflector (t10 at t10.org), posted by:
* keiji_katata at post.pioneer.co.jp
*
Hello all,
I posted a Japanese Map of the walking path to Kawasaki facility.
ftp.avc-pioneer.com/Mtfuji_7/Proposal/Jan08/SWG/Japanese Walking path for
Pioneer Kawasaki.ppt
Best regards,
Keiji Katata
PIONEER CORP.
TEL +81-49-279-2387
*
* For T10 Reflector information, send a message with
* 'info t10' (no quotes) in the message body to majordomo at t10.org


From keiji_katata at post.pioneer.co.jp  Wed Dec 26 22:06:10 2007
From: keiji_katata at post.pioneer.co.jp (keiji_katata at post.pioneer.co.jp)
Date: Thu, 27 Dec 2007 15:06:10 +0900
Subject: Posted: Pioneer counter proposal
Message-ID: <mailman.873.1441607324.22512.t10@sandbox.t10.org>

* From the T10 Reflector (t10 at t10.org), posted by:
* keiji_katata at post.pioneer.co.jp
*
Hello all,
I posted a counter proposal for 1/9 SWG.
ftp.avc-pioneer.com/Mtfuji_7/Proposal/Jan08/SWG/Pioneer Stream Model.doc
Best regards,
Keiji Katata
PIONEER CORP.
TEL +81-49-279-2387
*
* For T10 Reflector information, send a message with
* 'info t10' (no quotes) in the message body to majordomo at t10.org


From Frederick.Knight at netapp.com  Thu Dec 27 06:58:31 2007
From: Frederick.Knight at netapp.com (Knight, Frederick)
Date: Thu, 27 Dec 2007 09:58:31 -0500
Subject: Persistent Reservation Proposal - Group Reservations
Message-ID: <mailman.874.1441607324.22512.t10@sandbox.t10.org>

Formatted message: <A HREF="r0712271_f.htm">HTML-formatted message</A>

Would moving access restrictions from being based on the registration to
being based on a specific reservation type help for this?
Today, a bunch of initiators register - and that basically has no impact
on
anyones access.  When 1 initiator does the reservation, then that action
impacts all previous registrations (allowing continued access), and all
other
(non-registered) initiators (denying them access).  Anyone who registers
after that immediately joins the existing reservation.	That is what
this
group reservation is trying to deal with (getting free access under the
reservation just by doing a register - which is easy to do).
Could we create reservations types for:
  write exclusive - reserved only
  exclusive access - reserved only
This would create reservation types that require reservation actions to
allow
access.  A simple registration all by itself would still have no impact
on access
until an initiator also performed the reservation step.  Once any
initiator
uses this new type reservation, then a registered node would loose
access
(a reservation conflict status) until that initiator also performed a
reserve
function (with type reserved only).  This also means there would be
multiple
reservation holders (since every initiator does a reserve); so no need
to deal
with the one reservation holder case (#5 below).
Once this reservation type (reserved only) is in place, an initiator
that is already
registered but not reserved, could not do I/O or change the reservation
type (reserves
with other reservation types would fail).  Only a reserved initiator
could change
the reservation type (with a new reserve).
This would cover all cases below (1-6) except for #5.  As for #4
(preempt),
the process could be a little more protected.  With all the existing
reservation
types, the initiator just registers and preempts.  With these new types,
the
initiator would have to register, reserve, and then preempt.  Would that
meet
the #4 requirement, or do you feel preempt can't have any changes at
all?
My opinion is that a new reservation type could when it is used, create
new
requirements.  On the other hand, if you want to have preempt without
reserve,
then we could exempt that 1 function from the reserve requirement.
The question would be a group ID.  Is one needed? or would the simple
change
to require a matching reservation (of type reserved only) be enough?
Using a
simple shared value wouldn't work for this idea because of the problem
it
would create for preempt (register, reserve with shared value, then
preempt);
if you don't know the shared value, you can't preempt; so that would
make
using a shared value impracticle; unless we exempt preempt from the
reserve requirement, and just allow register; preempt (without a
reserve);
then, this approach could work.
More comments below on the existing proposal.
    Fred Knight
________________________________
From: Kevin D Butt [mailto:kdbutt at us.ibm.com] 
Sent: Monday, December 24, 2007 10:40 AM
To: Raymond Gilson
Cc: Christine R Knibloe; Knight, Frederick; Roger Cummings; t10 at t10.org
Subject: RE: Persistent Reservation Proposal - Group Reservations
Ray, 
Please see this font. 
Kevin D. Butt
SCSI & Fibre Channel Architect, Tape Firmware
MS 6TYA, 9000 S. Rita Rd., Tucson, AZ 85744
Tel: 520-799-2869 / 520-799-5280
Fax: 520-799-2723 (T/L:321)
Email address: kdbutt at us.ibm.com
http://www-03.ibm.com/servers/storage/ 
"Raymond Gilson" <raymond_gilson at symantec.com> 
12/22/2007 07:06 AM 
To
Kevin D Butt/Tucson/IBM at IBMUS 
cc
Christine R Knibloe/Tucson/IBM at IBMUS, "Knight, Frederick"
<Frederick.Knight at netapp.com>, "Roger Cummings"
<roger_cummings at symantec.com>, <t10 at t10.org> 
Subject
RE: Persistent Reservation Proposal - Group Reservations
Comments in line 
________________________________
From: Kevin D Butt [mailto:kdbutt at us.ibm.com] 
Sent: Friday, December 21, 2007 5:33 PM
To: Raymond Gilson
Cc: Christine R Knibloe; Knight, Frederick; Roger Cummings; t10 at t10.org
Subject: RE: Persistent Reservation Proposal - Group Reservations
Ray, 
Thanks for joining in.	Let me summarize what I think has been said by
all parties who have joined in these discussions. 
1) (From Ray) Some applications will have trouble providing a list of
Transport IDs. 
2) (From Fred) There is a desire to allow members of a cluster that were
not active at the creation of the reservation to join in. 
3) (From Kevin) Who can join or participate in a group reservation is
required to be controlled such that only those initiators that are part
of the cluster (i.e. group) can join. 
4) PREEMPT must be allowed (i.e., what we do cannot lock out PREEMPT or
make it not work correctly) 
5) Both Registrants Only and All Registrants types of functionality need
to be provided for. 
6) There should be an option for all target ports 
If we can't require a list of Transport ID's then it seems that the
suggested "shared secret" (not cryptographic, just some unique value
that is protected through obfuscation) is probably the best way to do
this.  This would be something akin to requiring the same reservation
key value.  However, using the reservation key does not seem to be
plausible because of how it is being used today.  What we need would be
some different value that would not be reportable via a Persistent
Reserve In.  This would keep third-party initiators from joining the
reservation.  If this new Group Reservation Identifier (GRID) were
added, that would take care of #1, #2, and #3 above. 
For #5 above, it seems that we could provide that by adding a bit in the
reserve command that indicates "All Participants are reservation
holders".  If set to one, then it acts like an All Registrants.  If set
to zero then it acts like Registrants Only.  This includes in the
unregistering. 
I'm not sure a bit is the right place for this.  Right now, it's
specified in the reservation type (registrants only, or all
registrants).  Creating a bit creates a place for conflicting
information to be supplied.  Are you suggesting this bit would apply to
only some reservation types, and be unused for other reservation types?
What would it mean if you did a registrants only reservation type, but
set the all registrants bit?
Another method would be to use all the existing reservation types (for
#5 above), but add a GRID bit to specify that the reservation applies to
only those that supply a matching GRID (all others get reservation
conflict until they supply a matching GRID).  Then it could in fact
apply to all reservation types.   
For #6 we use the ALL_TGT_PORTS bit the same as other reservations
today. 
Issues still to be resolved: 
a) Some systems won't want to require all initiators to send a
Persistent Reserve Out command.  Possible solution is to allow reserving
multiple initiators if a Transport ID list is sent.  Additional
initiators could join later if they have the GRID.  However this would
make it more complicated and if it is not needed I would rather not add
this option. 
In a practical sense, I cannot see how this could be avoided (all
initiators sending PRO) -- since PR requires trust and good behavior,
each initiator must make no assumption about what the protection level
is currently set at -- so it must verify the settings as the correct and
expected.  If the settings aren't as expected, it must bail out, or go
into error recovery to attempt to avoid messing up some other
application (a fist fight on the SAN for device control does nobody any
good).	I see no reason to provide for this (I do know that the current
command allows a registration for multiple ports, but I cannot imagine
using it in the real world).  
I'm not sure I understand the issue here.  How can a system that doesn't
want to send PR commands take advantage of the features offered by that
command?  Are you thinking of multi-path systems (where a single host
system has multiple initiators with access to the same target)?  How
does this new proposal make this different than the situation today
(where they need to use the transport ID list and the spec_i_pt bit), or
send PR-OUT from every initiator?  I guess I''m mostly agreeing that
good behavior is already required.
<<kdbutt: I am certainly willing to agree.  All could still be
registered by using the all_i_pt bit. However, I suspect there will be
those that will find this unacceptable.  Anybody who needs a way to add
all initiators who are currently registered to the group reservation,
please speak up (and comment on a method to accomplish this).>> 
I would suggest we do not want a way to add all currently registered
initiators to the group.  This would tend to have the potential to
enlarge the group beyond what is intended.  I'd prefer a method that
requires explicit action.
b) If the first I_T nexus sets the "All Participants are reservation
holders" to zero when it creates the reservation and then a subsequent
I_T nexus sets it to one, what is the behavior?  Change the type?
Reject?  Also, what is reported in the Report Full Status if All
Participants are reservation holders is set to zero?   
I don't think this is a problem -- once a reservation is established it
cannot be changed without a preempt, clear, or removal of the old.  If
this isn't either true, I would want the attempt to change it to get
rejected.  I would expect a change to require a preempt type operation.
<<kdbutt: I think the correct response for a new participant that
attempts to change the type is to reject a command that attempts to
change the type. 
I don't think you can require a preempt/clear in order to change the
type.  The whole point of PR is that a reservation is present at all
times; you can change the type, you can move the owner of the
reservation (such as preempt on a registrants only type), but you never
want to loose the protection provided by the PR (see note 10 in SPC4 -
section 5.6 - clearing).
For what to return in Report Full Status if  "All Participants are
reservation holders" is set to zero, I am concerned about confusion.  In
reality, only the first is a reservation holder and therefore only the
first should set the reservation_holder bit to one.  However, there
would now be two groups that cannot be distinguished.  There first is
not the reservation_holder but part of the reservation and the second is
not the reservation_holder and not part of the reservation.  I think we
should probably add a "group reservation participant" bit to distinguish
the two.>> .   
c) If we go to this method of using the GRID to determine who can join,
then the Reservation Key may or may not be different. 
c-1) if the Reservation Key is different, then a PREEMPT of a
Reservation Key will do what? 
c-2) if the Reservation Key is the same, then a PREEMPT will act the
same as an AR or RO reservation today. 
c-3) Do we require the Reservation Key to be the same?	 
Preempt is of a reservation, not a key.  The key's currently are not
compared, and have no valid use (by the device) except that each
initiator has registered one, and only one at a time.  We don't want to
change this behavior -- a key is random number assigned for some
external purpose that the device records and reports.  (My application
requires this to operate properly) 
<<kdbutt: Look at clause 5.6.10.4 of SPC-4r11.	This looks to me like
the Reservation Key is used to decide between unregistering I_T nexuses
with the sent reservation key or if the reservation key is that of the
reservation holder, then removing the reservation and registrations of
all that have that reservation key.  My intent is not to change the
current behavior.>> 
Agreed Kevin.  A Preempt should impact the registration/reservation of
all those initiators with a key that matches the one that is being
preempted - the same as current behavior.
d) Does this approach still have the issues that Roger was concerned
about (e.g., the corner cases)? 
I hope the use of a GRID would not introduce any new issues to SPR -- it
only prevents a registrant from becoming a reservation participant
without some external knowledge.  It doesn't prevent a registrant from
preempt, clear, or any other error recovery operations (and MUST not). 
I think this is one of the questions.  Error recovery is often one of
the cases where you end up with fist-fights out in the SAN over who owns
the device.  Hosts do exactly what you suggested above (host 1 checks
with PR-IN, doesn't like what it sees, and preempts and "fixes" it;
then, host 2 does exactly the same - and the fight is on).  It's
perfectly valid to want to leave this working as is.  I understand that
desire.  I just would like to discuss the possibility of improving the
situation.  If we can't or have other requirements not to change it,
that's fine. 
Thanks, 
Kevin D. Butt
SCSI & Fibre Channel Architect, Tape Firmware
MS 6TYA, 9000 S. Rita Rd., Tucson, AZ 85744
Tel: 520-799-2869 / 520-799-5280
Fax: 520-799-2723 (T/L:321)
Email address: kdbutt at us.ibm.com
http://www-03.ibm.com/servers/storage/ 
"Raymond Gilson" <raymond_gilson at symantec.com> 
12/21/2007 12:45 PM 
To
"Roger Cummings" <roger_cummings at symantec.com>, "Knight, Frederick"
<Frederick.Knight at netapp.com>, Kevin D Butt/Tucson/IBM at IBMUS 
cc
<t10 at t10.org>, Christine R Knibloe/Tucson/IBM at IBMUS 
Subject
RE: Persistent Reservation Proposal - Group Reservations
Several years ago I was trying to figure out a way to introduce a "JOIN"
function to the SPR.  The initiator would register, but that would not
grant it access to a reservation of the "joined only" type.  To join it,
the initiator would have to send a join SPR command -- we could add a
"shared secret" field to the join, so that only those initiators that
knew the secret could join. 
I think we will have a great deal of trouble with a "white list"
approach -- as an application, I have no idea what my port ID is (or
anything else for that matter). 
Would something like this make sense? 
Thanks, 
Ray Gilson 
________________________________
From: owner-t10 at t10.org [mailto:owner-t10 at t10.org] On Behalf Of Roger
Cummings
Sent: Tuesday, December 18, 2007 10:24 AM
To: Knight, Frederick; Kevin D Butt
Cc: t10 at t10.org; Christine R Knibloe
Subject: RE: Persistent Reservation Proposal - Group Reservations
Fred, 
The way you clean up from a disaster is to Preempt, that's what it's
there for. Most of the applications that I know that will actually issue
a Preempt make it a very special function that doesn't happen in the
normal flow, and one app at least DOES require manual intervention of an
operator before kicking off the preempt. 
Yes, today, a Preempt has to be issued through a registered I_T nexus,
but a registration with the SPEC_I_T bit doesn't have to come from an
already registered initiator - see Table 33 in SPC-4, and I don't
believe Kevin changed that in his proposal. 
For the future, however we define a "group" for the purposes of new
reservation types, we will have to make sure that an Initiator outside
of the "group" can issue a Preempt to handle the disaster recovery case.
Regards, 
Roger 
________________________________
From: Knight, Frederick [mailto:Frederick.Knight at netapp.com] 
Sent: Tuesday, December 18, 2007 10:56 AM
To: Roger Cummings; Kevin D Butt
Cc: t10 at t10.org; Christine R Knibloe
Subject: RE: Persistent Reservation Proposal - Group Reservations
My question has had to do with differentiating the disaster clean up 
case from the non-cooperating host case. 
How do I clean up from a disaster?  If all my "reserved" initiators 
melt down, and there aren't any of them left anymore (because of 
a site disaster, or whatever), how does some other node come along 
and clean up so it can gain access? 
Would it require manual intervention?  Or, is there a way in the
protocol 
that I can register and preempt the group reservation (does the use 
of the SPEC_I_PT bit allow this as you have suggested Roger).  I 
thought the SPEC_I_PT had to come from an already registered 
initiator (which in a disaster, none exist anymore). 
   Fred Knight 
________________________________
From: Roger Cummings [mailto:roger_cummings at symantec.com] 
Sent: Tuesday, December 18, 2007 10:03 AM
To: Kevin D Butt; Knight, Frederick
Cc: t10 at t10.org; Christine R Knibloe
Subject: RE: Persistent Reservation Proposal - Group Reservations
Kevin, 
I'm sorry, I don't think it's as cut and dried as you make out. This
gets into some of the corner cases that I listed in my first response. 
The point to be made in response to Fred's case is that a third-party
can create registrations for a downed initiator (via the SPEC_I_PT) bit,
so that when it comes up again it will be able to participate in the
reservation without having to register itself. 
Also, you say that "We have made provisions for adding members once the
reservation exists, but only one of the reservation holders can add
another entity." Two things in response to that: 
1) I didn't see any specific provision for adding members in your
proposal, so I presume you'd just issue another RESERVE with the same
type and the whole list of transport IDs to be included again, and thus
the Target would have a whole lot of work to do again to set up another
reservation. 
2) I that really what you want, that an member of the existing group can
reissue the RESERVE with a whole bunch of different TransportIDs,
perhaps excluding some that were previously there? 
Regards, 
Roger 
________________________________
From: owner-t10 at t10.org [mailto:owner-t10 at t10.org] On Behalf Of Kevin D
Butt
Sent: Monday, December 17, 2007 3:54 PM
To: Knight, Frederick
Cc: t10 at t10.org; Christine R Knibloe
Subject: RE: Persistent Reservation Proposal - Group Reservations
Fred, 
This is being proposed for SPC. 
There are multiple types of reservations.  In an environment where one
node of a cluster must join later, one of the other types can be used.
Either that or have an existing node in your cluster add the new node.
The whole intent of this Group reservation is to lock out everybody that
is not explicitly specified during the reserve.  We have made provisions
for adding members once the reservation exists, but only one of the
reservation holders can add another entity.  The new entity cannot add
itself.  This is the whole point of reservations (i.e., lock out others
|from doing stuff while I think I have exclusive rights). 
To put it in other word's, to allow somebody to join the reservation of
their own accord without permission is EXACTLY what I am trying to
protect against. 
Thanks, 
Kevin D. Butt
SCSI & Fibre Channel Architect, Tape Firmware
MS 6TYA, 9000 S. Rita Rd., Tucson, AZ 85744
Tel: 520-799-2869 / 520-799-5280
Fax: 520-799-2723 (T/L:321)
Email address: kdbutt at us.ibm.com
http://www-03.ibm.com/servers/storage/ 
"Knight, Frederick" <Frederick.Knight at netapp.com> 
12/17/2007 01:38 PM 
To
Kevin D Butt/Tucson/IBM at IBMUS 
cc
Subject
RE: Persistent Reservation Proposal - Group Reservations
Sorry, you can't require everyone to register before the reserve. 
That's like saying my whole cluster can't boot because 1 node is down.
You need 
to have a way for a "down" initiator to join the fun after the fact. 
I helped write a host cluster product that used a shared tape (failover
model).  The 
backup application would write to the tape.  If a system failure ever
happened, the 
backup application would failover to a different host.	It would skip
backwards on 
the tape for a few records, recognize where it left off, and then resume
operation. 
BUT, for some protection, we used reservations to make sure only 1
initiator at a 
time could access the tape.  The interesting point however, is that we
were in the 
process of upgrading from old SCSI-2 RESERVE to using PR.  Because, we
also 
have multiple HBAs in the host, and we wanted to be able to use more
than 1 of 
those HBAs (so we needed multiple reservations - aka PR).  Having this
idea 
(group reservations) would have been a real nice addition. 
As for the RA/AR differences.  It seemed to be timing.	Registrants Only
was fairly 
early on (as I remember), and so implemented by several O/S vendors.
Later on, 
some issues were found (which got complicated spec-ees added to
address), but also, 
the All Registrants was added (which didn't have those issues).  But,
since there were 
implementations, it couldn't be removed like the other old PR types that
no one ever 
used.  Anyway, I agree, they offer basically the same capabilities, but
RO is already 
out there, and AR is probably what new implementers are using (it's
easier to understand 
and implement from the host side).  Most of the differences are already
documented, 
so there wouldn't be that much extra for you to write to have both types
(which I think 
would be better than bit somewhere - do it the same way all the others
are done).  But, 
you could also just do the AR version, and let someone else add the RO
version if they 
want it. 
Are you proposing this for tape only? or SPC in general?  I assume SPC
in general. 
  Fred Knight 
________________________________
From: Kevin D Butt [mailto:kdbutt at us.ibm.com] 
Sent: Monday, December 17, 2007 9:51 AM
To: Roger Cummings
Cc: t10 at t10.org
Subject: RE: Persistent Reservation Proposal - Group Reservations
Roger, 
Thank you for your feedback.  I am certainly willing to entertain  other
methods for accomplishing the end goal in an easier fashion.  I am not
sure I understand how your proposed method makes it more backward
compatible.  In my proposal PRin would show a different type of
reservation and hence the application clients would not try to join the
reservation because they don't know about the type.  In your proposal,
application clients would not be allowed to register.  This is a
deviation from what they can always do today - unless there is a
resource issue.  This seems more disruptive to me.  I would assume that
there would be a new additional sense code added for UNABLE TO REGISTER
BECAUSE A GROUP RESERVATION IS IN PLACE (or analogous).  This would be a
new thing for failure to register and there would be pain at the
register point.  Perhaps that is better than at the reserve point - but
I would think that it would be better handled as a reservation conflict
since that is what it is instead of something the application client
does not understand. 
As for "all registrants" type vs. "registrants only" I didn't see where
the difference would be interesting, but I am not opposed to providing a
way to switch between which of these two types is done.  Whether it is
additional types or some bit during registration etc. 
As for some of the corner cases mentioned below, if each I_T nexus that
is supposed to be part of the group reservation is required to be
registered before the reservation is made, and if the reservation is
released when the last group reservation participant is unregistered,
then I think we don't have an issue. 
I would prefer that we work together to shape a mutually beneficial
proposal as opposed to have "competing" proposals.  I am willing to
modify my proposal where it can be made easier and such.  I am not sold
that my proposed method is the only way or even the best - it's just the
way I thought of doing it.  I admit that I have always been very
confused about the usefulness of RA and AR types.  They make absolutely
no sense in the tape world. 
Thanks, 
Kevin D. Butt
SCSI & Fibre Channel Architect, Tape Firmware
MS 6TYA, 9000 S. Rita Rd., Tucson, AZ 85744
Tel: 520-799-2869 / 520-799-5280
Fax: 520-799-2723 (T/L:321)
Email address: kdbutt at us.ibm.com
http://www-03.ibm.com/servers/storage/ 
"Roger Cummings" <roger_cummings at symantec.com> 
Sent by: owner-t10 at t10.org 
12/14/2007 12:10 PM 
To
Kevin D Butt/Tucson/IBM at IBMUS 
cc
<t10 at t10.org> 
Subject
RE: Persistent Reservation Proposal - Group Reservations
Kevin, 
First of all, let me say that I completely support what you're trying to
do here. I think that providing a method in persistent reservations
(PRs) to support shared access between ONLY a specifically-designated
set of systems is a worthy goal, and something we should do in SPC-4. 
Adding a set of Transport IDs to Reserve as per your document 08-024 &
08-025 is certainly possible, but it's a massive change to the way that
PRs work today, and it throws up a bunch of nasty corner cases and
backwards compatibility issues. 
The massive change comes from the fact that now the Target will have to
remember which registrations are in the Reservation, and which are not.
It will probably have to preserve all of the transport information for
the life of the reservation. 
The corner cases are things like, what happens if there's no longer a
registration that corresponds to the transport ID in the Reserve? Does
the Reserve succeed? What happens if a registration comes in later,
after the reservation has been established - does that device it get
access? 
Backwards compatibility issues may arise like this: An existing device
registers, and finds it has no access, so it does a PR In and finds out
that a reservation is in place, retries its access and still it has no
access. What does it do next, preempt the reservation because it assumes
the Target is broken? 
Reserve also has to be an "atomic" command, and I've always thought that
was why it's functionality is as compact as it is today. Most of the
complex operations related to addresses and keys are done at
registration time, and those operations don't have to be atomic. 
One more thing: you chose for your new "group" reservations to follow
the "all registrants" approach is terms of the definition of the
reservation holder. While that's fine by me (obviously), I suspect there
are also situations where group reservations that follow the
"registrants only" approach might be useful. 
The bottom line from my point of view is this: Your proposal is feasible
and we can probably make it work. But I wonder if there's an easier way
to achieve the same goal that is more compatible with existing practice
and requires less of a change in functionality on the Target side. 
What if we didn't add any new reservations types, but instead added some
new functionality to the registration process? What I'm thinking of a
new Register feature that causes the Target to kill all existing
registrations, create the registrations identified in the transport IDs
in the Register command, and not accept any future registrations. That
way, we don't need any changes to Reserve, and an Initiator with
existing functionality would just not be able to register and therefore
would not be confused. 
Does that make sense to you? Is there a chance this is an easier
approach? If so, I'll write up a detailed proposal that's the equivalent
of 08-025r0 and we can compare and contrast at the next CAP. 
Again, thanks for getting this started, I think it's a worthwhile
endeavor and I'll be glad to put some cycles towards defining this sort
of functionality for SPC-4. 
Regards, 
Roger 
________________________________
From: owner-t10 at t10.org [mailto:owner-t10 at t10.org] On Behalf Of Kevin D
Butt
Sent: Monday, December 10, 2007 4:18 PM
To: t10 at t10.org
Subject: Persistent Reservation Proposal - Group Reservations
I have posted two documents related to an additional Persistent
Reservation Type.  The first document is a presentation on where
persistent reservations are today and where they fall short in the
scenarios covered by the proposal.  It also covers the intent of the
proposal and what will be proposed.  The second is the actual proposal 
Your PDF file will be posted at:
http://www.t10.org/ftp/t10/document.08/08-024r0.pdf 
http://www.t10.org/ftp/t10/document.08/08-025r0.pdf
Normally, the posting/archiving process takes about 30 minutes. 
Kevin D. Butt
SCSI & Fibre Channel Architect, Tape Firmware, IBM
MS 6TYA, 9000 S. Rita Rd., Tucson, AZ 85744
Tel: 520-799-2869 / 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 lohmeyer at t10.org  Sat Dec 29 23:00:40 2007
From: lohmeyer at t10.org (T10 Document Administrator)
Date: Sun, 30 Dec 2007 00:00:40 -0700
Subject: Recent T10 documents uploaded since 2007/12/23
Message-ID: <mailman.875.1441607324.22512.t10@sandbox.t10.org>

* From the T10 Reflector (t10 at t10.org), posted by:
* T10 Document Administrator <lohmeyer at t10.org>
*
Proposals
---------
Working Drafts
--------------
(Report generated on 2007/12/30 at 00:00:40)
*
* For T10 Reflector information, send a message with
* 'info t10' (no quotes) in the message body to majordomo at t10.org