From lohmeyer at t10.org  Sat Jan  3 23:00:50 2009
From: lohmeyer at t10.org (T10 Document Administrator)
Date: Sun, 4 Jan 2009 00:00:50 -0700
Subject: Recent T10 documents uploaded since 2008/12/28
Message-ID: <mailman.0.1441607347.22516.t10@sandbox.t10.org>

* From the T10 Reflector (t10 at t10.org), posted by:
* T10 Document Administrator <lohmeyer at t10.org>
*
Proposals
---------
Agenda for T10 Meeting #89 January 2009
(by: John Lohmeyer)
T10/08-458r3   Uploaded: 2008/12/31   61829 bytes
http://www.t10.org/cgi-bin/ac.pl?t=d&f=08-458r3.pdf
Request of Information Regarding Exceptions to the INCITS Adoption
Policy
(by: Lynn Barra)
T10/09-022r0   Uploaded: 2008/12/31   11853 bytes
http://www.t10.org/cgi-bin/ac.pl?t=d&f=09-022r0.htm
Request of Information Regarding Exceptions to the INCITS Adoption
Policy
(by: Lynn Barra)
T10/09-022r0   Uploaded: 2008/12/31   70976 bytes
http://www.t10.org/cgi-bin/ac.pl?t=d&f=09-022r0.pdf
Non-Automatic adoption of ISO/IEC Standards as American National
Standards
(by: John Lohmeyer)
T10/09-023r0   Uploaded: 2008/12/31   2669 bytes
http://www.t10.org/cgi-bin/ac.pl?t=d&f=09-023r0.htm
Non-Automatic adoption of ISO/IEC Standards as American National
Standards
(by: John Lohmeyer)
T10/09-023r0   Uploaded: 2008/12/31   37817 bytes
http://www.t10.org/cgi-bin/ac.pl?t=d&f=09-023r0.pdf
Working Drafts
--------------
(Report generated on 2009/01/04 at 00:00:50)
*
* 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  Mon Jan  5 10:05:10 2009
From: Bill.Martin at emulex.com (Bill.Martin at emulex.com)
Date: Mon, 5 Jan 2009 10:05:10 -0800
Subject: COMINIT received during speed negotiation states.
Message-ID: <mailman.1.1441607347.22516.t10@sandbox.t10.org>

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

During the SP9:SAS_WindowNotSupported and SP14:SAS_Fail states, COMINIT is
required to be ignored (it is not specified as a specific transition out of
these states.  I realize that after a Hot-Plug timeout another COMINIT will
be generated; however, is there any reason that a COMINIT should NOT be
detected in these two states?
If there is no reason not to detect this in these states, I will generate a
proposal for SPL to allow a transition based on detection of COMINIT in these
two states.
Thanks,
Bill Martin
Emulex
Office of Technology
Industry Standards
916 772-3658
916 765-6875 (Cell)
bill.martin at emulex.com


From greg.mcsorley at amphenol-gcs.com  Tue Jan  6 06:04:30 2009
From: greg.mcsorley at amphenol-gcs.com (Greg McSorley)
Date: Tue, 6 Jan 2009 09:04:30 -0500
Subject: PHY WG teleconference minutes posted
Message-ID: <mailman.2.1441607347.22516.t10@sandbox.t10.org>

* From the T10 Reflector (t10 at t10.org), posted by:
* "Greg McSorley" <greg.mcsorley at amphenol-gcs.com>
*
Alvin & All,
Happy New Year, hope everybody's Holidays were enjoyable.
I've got to say that of all the proposals posted since this con call, I
like Tyco's the best.
Since this has been the only one posted, does this still mean that next
weeks meeting is still the deadline for connector proposals and do we
have any indication that there will be any more proposals? 
Fore!!
Greg
Greg McSorley 
Mobile (508)561-2903
greg.mcsorley at amphenol-gcs.com 
www.amphenol.com 
www.cablesondemand.com 
-----Original Message-----
From: owner-t10 at t10.org [mailto:owner-t10 at t10.org] On Behalf Of
Alvin.Cox at seagate.com
Sent: Friday, December 12, 2008 1:41 PM
To: t10 at t10.org
Subject: PHY WG teleconference minutes posted
The minutes of the 12/11 conference call are posted at: 
  http://www.t10.org/cgi-bin/ac.pl?t=d&f=09-016r0.pdf
Also note that the new SASWDP code is available for verification at: 
http://www.t10.org/cgi-bin/ac.pl?t=d&f=09-015r0.pdf
<http://www.t10.org/cgi-bin/ac.pl?t=d&f=09-015r0.pdf&gt;  
http://www.t10.org/cgi-bin/ac.pl?t=d&f=09-015r0.zip 
Alvin Cox
Seagate Technology, LLC
Office 405-392-3738
Cell 405-206-4809
E-Mail	alvin.cox at seagate.com
*
* 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 Jan  6 23:11:59 2009
From: keiji_katata at post.pioneer.co.jp (keiji_katata at post.pioneer.co.jp)
Date: Wed, 7 Jan 2009 16:11:59 +0900
Subject: A Request to MMC WG from BDA
Message-ID: <mailman.3.1441607347.22516.t10@sandbox.t10.org>

* From the T10 Reflector (t10 at t10.org), posted by:
* keiji_katata at post.pioneer.co.jp
*
Dear Bill,
BDA has a request to MMC6.
For Current/Maximum Capacity Descriptor of the READ FORMAT CAPACITIES command
there are two implementations on BD-R drive with a Blank BD-R disc. The 1st
implementation reports Data Area size as Spare Area included that is
specified
by BD-R specification. The reported value includes Inner Spare Area that host
never be able to Read/Write. The 2nd implementation reports User Data Area
size
that does not include the Inner Spare Area.
MMC5-BSR+INCITES=430.pdf on page 471
Table 468 ? Current/Maximum Capacity Descriptor for Unformatted or Blank
Media
BD-R: The number of sectors in all the data zones on the media.
MMC5 used a term "data zone" for two meanings. The 1st meaning is Data Zone
of
BD-RE/R that includes user data recordable area and spare area. The 2nd
meaning
is user data recordable area. These two usages allow these different
implementations of BD-R drives.
On the other hand MMC3/MMC4 specifies generic definition of Current/Maximum
Capacity Descriptor of the READ FORMAT CAPACITIES command as follows;
mmc3r10g.pdf Table 210 on page 201
01b Unformatted Media.
The reported value is for the maximum formatted capacity for this media. For
DDCD/CD-RW medium, the value reported is the maximum possible when using
Format
Type 10h.
mmc4r05a.pdf Table 416 on page 347
01b Unformatted Media.
The reported value is for the maximum formatted capacity for this media.
These two descriptions said that the original intention of this field
requests
to show the possible maximum recordable / readable capacity of a disc.
Fortunately Data Zone of CD/DVD does not include Spare Area. Then capacity of
all Data Zones of CD/DVD disc follows the original intention.
BDA concluded that two different implementations do not cause any trouble and
both implementations are reasonable. Therefore BDA would like to request to
MMC
WG that MMC6 may have a note that explains these two implementations of the
BD-R
writable drives as follows.
Note: There are two implementations for BD-R writable drive. One
implementation
reports a value that includes Inner Spare Area. Another implementation
reports a
value of the maximum user data recordable area. Host may use the third
descriptor values of Format Type 32h or READ TRACK INFORMATION Command
response
to obtain a maximum recordable capacity of the Blank BD-R disc.
I personally think that MMC6 may have same table with Table 210 of MMC3 to
explain this original intention and then explain each medium definitions.
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 George.Penokie at lsi.com  Wed Jan  7 07:24:32 2009
From: George.Penokie at lsi.com (Penokie, George)
Date: Wed, 7 Jan 2009 08:24:32 -0700
Subject: SPC-4 Protocol Specific Logical Unit mode page
Message-ID: <mailman.4.1441607347.22516.t10@sandbox.t10.org>

* From the T10 Reflector (t10 at t10.org), posted by:
* "Penokie, George" <George.Penokie at lsi.com>
*
Mike,
Thanks for pointing this out. I have submitted a T10 proposal to fix it as
you suggested.
Bye for now, 
George Penokie
LSI Corporation 
3033 41st St. NW 
Suite 100 
Rochester, MN 55901
507-328-9017 
george.penokie at lsi.com
-----Original Message-----
From: owner-t10 at t10.org [mailto:owner-t10 at t10.org] On Behalf Of Mike Berhan
Sent: Thursday, December 18, 2008 8:33 AM
To: t10 at t10.org
Subject: SPC-4 Protocol Specific Logical Unit mode page
* From the T10 Reflector (t10 at t10.org), posted by:
* "Mike Berhan" <mikeb at bustrace.com>
*
Advanced apologies if this has already been pointed out.
Page 444, Table 359, SPC-4 r17.  This table defines the Protocol Specific
Logical Unit mode page.  Offset 2, bits 7-4 are reserved.  Offset 3+ are the
protocol specific mode parameters.
Page 561, Table 221, SAS-2 r15 (same applies to SAS-1).  This table details
the SAS version of this mode page.  Note, however, that SAS defines bit 4
offset 2 as the "Transport Layer Retries" bit.
Reserved is well defined as:
3.3.8 reserved: A keyword referring to bits, bytes, words, fields and code
values that are set aside for future standardization. A reserved bit, byte,
word or field shall be set to zero, or in accordance with a future extension
to this standard. Recipients are not required to check reserved bits, bytes,
words or fields for zero values. Receipt of reserved code values in defined
fields shall be reported as an error.
The SAS specification conflicts with the SPC specification in this regard.
I believe SPC-4 should be amended to clarify this conflict.  Perhaps define
that one bit, or all four bits, as protocol specific as opposed to reserved.
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
*
* 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  Thu Jan  8 11:46:34 2009
From: roger_cummings at symantec.com (Roger Cummings)
Date: Thu, 8 Jan 2009 12:46:34 -0700
Subject: Next week's T10 meeting attenders PLEASE READ
Message-ID: <mailman.5.1441607347.22516.t10@sandbox.t10.org>

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

Folks,
Some additional points for those attending next week's T10 meetings:
1) DIRECTIONS AND TOLLS
All of the links to directions given in the meeting announcement,
namely:
Directions from Orlando Airport (MCO): http://tinyurl.com/n7sm9
Directions from  Daytona Beach (DAB):  http://tinyurl.com/guw56
Directions from  Sanford (SFB):
http://tinyurl.com/n9ms7
still work. Note that these directions are NOT included in meeting
announcement at www.t10.org.
HOWEVER for some reason, just this week Google maps has taken to setting
a route from Orlando International Airport to the hotel that involves
taking surface roads to join up with I-4, and is complex to follow
around the airport. While that route will work, and may avoid all tolls,
I'd still personally recommend using the Greeneway as follows:
   a)	      Head towards the North exit from Orlando International
Airport, and then take the first ramp on the right which signposted to
SR-528-TOLL East towards COCOA/ KENNEDY SPACE CENTER;
   b)	      After 3.9 miles, take EXIT 16 towards SR-417/ TAMPA/
ORLANDO; 
   c)	      After 0.3 miles, take the SR-417-TOLL North exit on the
LEFT toward ORLANDO/ SANFORD (see below for info on the tolls on
SR-417);
   d)	      After about 28 miles, take the RINEHART ROAD exit, EXIT
54;
   e)	      At the end of the ramp, turn LEFT onto RINEHART RD;
   f)	       After about 1.5 miles turn RIGHT onto HE THOMAS JR PKWY,
and cross over I-4;
   g)	      After about 0.7 miles, turn LEFT onto INTERNATIONAL PKWY,
and then take the second left turn into the Marriott.
This route from Orlando Airport avoids downtown Orlando and the busy
stretch of I-4, but involves paying three tolls - two of 50c each and
one of $2. There are exact change lanes at the first two toll booths, so
bring some quarters, or see item #2 below. 
Also, if you're following other directions from Orlando Airport that go
via SR-408 and I-4, there's a 75c toll on that route too!
Note that the last step of each of the sets of directions from Google
Maps is incorrect - it is no longer necessary to make a U-turn on
International Parkway at Heathrow Park Lane - you can instead take the
2nd left on International Parkway directly into the hotel complex.
2) PLATEPASS
If you're planning to rent a car from Avis, Budget, or Hertz, check if
you can take advantage of a scheme called PlatePass that lets rental
cars use the automated EPass or SunPass lanes (including the full speed
ones) on Florida tollways without needing a radio tag. See
http://www.platepass.com for more information. 
The cost of this scheme is $2.50 for each day you use it, plus the
normal tolls. It's charged back to your car rental company, who
typically make a separate charge on your credit card. You can get
receipts for the PlatePass charges from the website listed above,
although when I used the scheme in 2007 took 2 weeks for the receipt to
be listed.
It's important to make sure you're covered by this scheme in advance
because otherwise using those same lanes without a radio tag is a
violation that normally results in a minimum $150 fine per instance. 
If you're planning to drive from the Orlando airport to the hotel in
rush hour, PlatePass will likely save you 10 minutes on the trip.
3) TRAFFIC INFORMATION
There's a good real time travel & traffic reporting system available by
calling 511 on your mobile phone, or at:
http://www.fl511.com
Select Orlando as the Preset Region, and select the Congestion Layer.
4) MAP
If you'd like a good single sheet map of the major roads in Central
Florida (including toll booths), please see:
https://epass.oocea.com/Corporate/travel/assets/expressway_map_med_res_v
2.jpg
On this map the hotel is located near the top center of the map close to
CR 46A just west of the junction with I-4.
5) WEATHER
The forecast for next week calls for mostly sunny days with highs around
70, and overnight lows in the high 40s. The probability of precipitation
is 30% for Sunday, and 10% or less for the other days.
6) HOTEL ROOMS & MULTIMEDIA
The hotel has been undergoing an upgrade recently, and I'm told that now
MOST of the sleeping rooms now conform to the "next generation room"
displayed at http://www.experiencemarriott.com/ - see specifically the
"plug in" section. So if you'd like to attach your laptop or DVD player
to the panel for the LCD TV, my strong advice is to bring the correct
cables with you from home.
7) FOOD
I'm sorry, there will NOT be a reception this week - in the current
economic situation it couldn't be justified.
However, I've a guide to the restaurants in the area around the hotel as
09-037r0. See http://www.t10.org/cgi-bin/ac.pl?t=d&f=09-037r0.htm for
the interactive version.
One final point: If anyone who has made a reservation at the hotel has
to cancel, could they please let me know by replying to this message?
This is just so that my numbers for the catering are accurate.
I look forward to seeing everyone next week. 
Regards,
Roger Cummings
SYMANTEC
roger_cummings at symantec.com


From keiji_katata at post.pioneer.co.jp  Fri Jan  9 00:10:51 2009
From: keiji_katata at post.pioneer.co.jp (keiji_katata at post.pioneer.co.jp)
Date: Fri, 9 Jan 2009 17:10:51 +0900
Subject: A Request to MMC WG from BDA
Message-ID: <mailman.6.1441607347.22516.t10@sandbox.t10.org>

* From the T10 Reflector (t10 at t10.org), posted by:
* keiji_katata at post.pioneer.co.jp
*
Dear Bill,
I made a mistake. I would like to update the description of a note as
follows;
Note: There are two implementations for BD-R writable drive. One
implementation
reports a value that includes Inner Spare Area. Another implementation
reports a
value of the maximum user data recordable area. Host may use the third
descriptor values of Format Type 32h to obtain a maximum recordable capacity
of
the Blank BD-R disc.
MMC5 defines a Blank BD-R disc as follows;
The default mode for a blank BD-R disc is SRM with no spares allocated.
Therefore READ TRACK INFORMATION Command will report Data Zone that includes
Inner Spare Area.
When FORMAT UNIT Command is not used the Inner Spare Area size is set to 0
(not
allocated) and the user data recordable area of BD-R disc is same with Data
Zone
size. I'm sorry that I forgot this.
Best regards,
Keiji Katata
PIONEER CORP.
keiji_katata at post.pioneer.co.jp@t10.org on 2009/01/07 16:11:59
$BAw?.<T(B:	  owner-t10 at t10.org
$B08 at h(B:  Bill McFerrin <billmc37 at ctesc.net>
cc:    T10 Reflector <T10 at t10.org>
$B7oL>(B:  A Request to MMC WG from BDA
* From the T10 Reflector (t10 at t10.org), posted by:
* keiji_katata at post.pioneer.co.jp
*
Dear Bill,
BDA has a request to MMC6.
For Current/Maximum Capacity Descriptor of the READ FORMAT CAPACITIES command
there are two implementations on BD-R drive with a Blank BD-R disc. The 1st
implementation reports Data Area size as Spare Area included that is
specified
by BD-R specification. The reported value includes Inner Spare Area that host
never be able to Read/Write. The 2nd implementation reports User Data Area
size
that does not include the Inner Spare Area.
MMC5-BSR+INCITES=430.pdf on page 471
Table 468 ? Current/Maximum Capacity Descriptor for Unformatted or Blank
Media
BD-R: The number of sectors in all the data zones on the media.
MMC5 used a term "data zone" for two meanings. The 1st meaning is Data Zone
of
BD-RE/R that includes user data recordable area and spare area. The 2nd
meaning
is user data recordable area. These two usages allow these different
implementations of BD-R drives.
On the other hand MMC3/MMC4 specifies generic definition of Current/Maximum
Capacity Descriptor of the READ FORMAT CAPACITIES command as follows;
mmc3r10g.pdf Table 210 on page 201
01b Unformatted Media.
The reported value is for the maximum formatted capacity for this media. For
DDCD/CD-RW medium, the value reported is the maximum possible when using
Format
Type 10h.
mmc4r05a.pdf Table 416 on page 347
01b Unformatted Media.
The reported value is for the maximum formatted capacity for this media.
These two descriptions said that the original intention of this field
requests
to show the possible maximum recordable / readable capacity of a disc.
Fortunately Data Zone of CD/DVD does not include Spare Area. Then capacity of
all Data Zones of CD/DVD disc follows the original intention.
BDA concluded that two different implementations do not cause any trouble and
both implementations are reasonable. Therefore BDA would like to request to
MMC
WG that MMC6 may have a note that explains these two implementations of the
BD-R
writable drives as follows.
Note: There are two implementations for BD-R writable drive. One
implementation
reports a value that includes Inner Spare Area. Another implementation
reports a
value of the maximum user data recordable area. Host may use the third
descriptor values of Format Type 32h or READ TRACK INFORMATION Command
response
to obtain a maximum recordable capacity of the Blank BD-R disc.
I personally think that MMC6 may have same table with Table 210 of MMC3 to
explain this original intention and then explain each medium definitions.
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
*
* 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 Jan 10 23:00:51 2009
From: lohmeyer at t10.org (T10 Document Administrator)
Date: Sun, 11 Jan 2009 00:00:51 -0700
Subject: Recent T10 documents uploaded since 2009/01/04
Message-ID: <mailman.7.1441607347.22516.t10@sandbox.t10.org>

* From the T10 Reflector (t10 at t10.org), posted by:
* T10 Document Administrator <lohmeyer at t10.org>
*
Proposals
---------
ADC-3 SET AUTOMATION DEVICE ATTRIBUTE command
(by: Rod Wideman)
T10/08-021r3   Uploaded: 2009/01/07   57814 bytes
http://www.t10.org/cgi-bin/ac.pl?t=d&f=08-021r3.pdf
SMC-3, Report Element Information
(by: Curtis Ballard)
T10/08-066r6   Uploaded: 2009/01/06   126003 bytes
http://www.t10.org/cgi-bin/ac.pl?t=d&f=08-066r6.pdf
SBC - Thin Provisioning
(by: Frederick Knight)
T10/08-149r8   Uploaded: 2009/01/09   281387 bytes
http://www.t10.org/cgi-bin/ac.pl?t=d&f=08-149r8.pdf
SMC-3 Report Volume Information
(by: Curtis Ballard)
T10/08-215r3   Uploaded: 2009/01/06   121846 bytes
http://www.t10.org/cgi-bin/ac.pl?t=d&f=08-215r3.pdf
SMC-3 Use of LOGICAL UNIT COMMUNICATION FAILURE
(by: Rod Wideman)
T10/08-271r1   Uploaded: 2009/01/07   14653 bytes
http://www.t10.org/cgi-bin/ac.pl?t=d&f=08-271r1.pdf
SMC-3 Use of LOGICAL UNIT COMMUNICATION FAILURE
(by: Rod Wideman)
T10/08-271r2   Uploaded: 2009/01/07   14507 bytes
http://www.t10.org/cgi-bin/ac.pl?t=d&f=08-271r2.pdf
SMC-3 New additional sense codes tracking document
(by: Rod Wideman)
T10/08-272r3   Uploaded: 2009/01/07   17988 bytes
http://www.t10.org/cgi-bin/ac.pl?t=d&f=08-272r3.pdf
Proposal for SAS 2.1 Specification to Enable Support for Active Cables
(by: Gourgen Oganessyan)
T10/08-358r2   Uploaded: 2009/01/08   248156 bytes
http://www.t10.org/cgi-bin/ac.pl?t=d&f=08-358r2.pdf
SAS-2.1 / SPL An optical OOB method
(by: Brian Day)
T10/08-439r1   Uploaded: 2009/01/06   281994 bytes
http://www.t10.org/cgi-bin/ac.pl?t=d&f=08-439r1.pdf
SBC-3 Host block alignment detection
(by: Frederick Knight)
T10/09-004r1   Uploaded: 2009/01/09   79825 bytes
http://www.t10.org/cgi-bin/ac.pl?t=d&f=09-004r1.pdf
SBC-3 Thin Provisioning Threshold Notification
(by: Frederick Knight)
T10/09-011r1   Uploaded: 2009/01/09   32757 bytes
http://www.t10.org/cgi-bin/ac.pl?t=d&f=09-011r1.pdf
SAS-2 SASWDP V1.7
(by: Harvey Newman)
T10/09-024r0   Uploaded: 2009/01/05   23936 bytes
http://www.t10.org/cgi-bin/ac.pl?t=d&f=09-024r0.pdf
SAS-2 SASWDP V1.7
(by: Harvey Newman)
T10/09-024r0   Uploaded: 2009/01/05   12011 bytes
http://www.t10.org/cgi-bin/ac.pl?t=d&f=09-024r0.zip
Public Review Comment #1 on BSR INCITS 457-200x (SAS-2)
(by: Harvey Newman)
T10/09-025r0   Uploaded: 2009/01/05   23507 bytes
http://www.t10.org/cgi-bin/ac.pl?t=d&f=09-025r0.pdf
Proposed SAS 2.1 Revison 0
(by: George Penokie)
T10/09-026r0   Uploaded: 2009/01/06   6087435 bytes
http://www.t10.org/cgi-bin/ac.pl?t=d&f=09-026r0.pdf
3M Proposal for a New High Density Mini-SAS System
(by: Charles Staley)
T10/09-027r0   Uploaded: 2009/01/06   330475 bytes
http://www.t10.org/cgi-bin/ac.pl?t=d&f=09-027r0.pdf
SASWDP V1.8
(by: Mathieu Gagnon)
T10/09-028r0   Uploaded: 2009/01/06   48141 bytes
http://www.t10.org/cgi-bin/ac.pl?t=d&f=09-028r0.pdf
SASWDP V1.8
(by: Mathieu Gagnon)
T10/09-028r0   Uploaded: 2009/01/06   12479 bytes
http://www.t10.org/cgi-bin/ac.pl?t=d&f=09-028r0.zip
SPC-4: Virtual Device Inquiry page
(by: Kevin Butt)
T10/09-033r0   Uploaded: 2009/01/07   77819 bytes
http://www.t10.org/cgi-bin/ac.pl?t=d&f=09-033r0.pdf
SPC-4: EMail comment recieved from Mike Berhan busTRACE
(by: George Penokie)
T10/09-034r0   Uploaded: 2009/01/07   49244 bytes
http://www.t10.org/cgi-bin/ac.pl?t=d&f=09-034r0.pdf
SMC-3 Telephone conference January 7th Agenda
(by: Curtis Ballard)
T10/09-035r0   Uploaded: 2009/01/07   15300 bytes
http://www.t10.org/cgi-bin/ac.pl?t=d&f=09-035r0.pdf
Minutes SMC-3 07 January 2009
(by: Kevin Butt)
T10/09-036r0   Uploaded: 2009/01/07   45442 bytes
http://www.t10.org/cgi-bin/ac.pl?t=d&f=09-036r0.pdf
Jan 09 Restaurant Guide
(by: Roger Cummings)
T10/09-037r0   Uploaded: 2009/01/07   331 bytes
http://www.t10.org/cgi-bin/ac.pl?t=d&f=09-037r0.htm
Jan 09 Restaurant Guide
(by: Roger Cummings)
T10/09-037r0   Uploaded: 2009/01/07   133759 bytes
http://www.t10.org/cgi-bin/ac.pl?t=d&f=09-037r0.pdf
SBC-3, More background scan clean-up
(by: Mark Evans)
T10/09-038r0   Uploaded: 2009/01/09   92456 bytes
http://www.t10.org/cgi-bin/ac.pl?t=d&f=09-038r0.pdf
Working Drafts
--------------
(Report generated on 2009/01/11 at 00:00:51)
*
* For T10 Reflector information, send a message with
* 'info t10' (no quotes) in the message body to majordomo at t10.org


From billmc37 at ctesc.net  Mon Jan 12 07:33:19 2009
From: billmc37 at ctesc.net (Bill McFerrin)
Date: Mon, 12 Jan 2009 09:33:19 -0600
Subject: A Request to MMC WG from BDA
Message-ID: <mailman.8.1441607347.22516.t10@sandbox.t10.org>

* From the T10 Reflector (t10 at t10.org), posted by:
* Bill McFerrin <billmc37 at ctesc.net>
*
Thank you,
We shall put this on our agenda.
Kind Regards,
Bill McFerrin
keiji_katata at post.pioneer.co.jp wrote:
> Dear Bill,
>
> BDA has a request to MMC6.
>
> For Current/Maximum Capacity Descriptor of the READ FORMAT CAPACITIES
command
> there are two implementations on BD-R drive with a Blank BD-R disc. The 1st
> implementation reports Data Area size as Spare Area included that is
specified
> by BD-R specification. The reported value includes Inner Spare Area that
host
> never be able to Read/Write. The 2nd implementation reports User Data Area
size
> that does not include the Inner Spare Area.
>
> MMC5-BSR+INCITES=430.pdf on page 471
> Table 468 ? Current/Maximum Capacity Descriptor for Unformatted or Blank
Media
> BD-R: The number of sectors in all the data zones on the media.
>
> MMC5 used a term "data zone" for two meanings. The 1st meaning is Data Zone
of
> BD-RE/R that includes user data recordable area and spare area. The 2nd
meaning
> is user data recordable area. These two usages allow these different
> implementations of BD-R drives.
> On the other hand MMC3/MMC4 specifies generic definition of Current/Maximum
> Capacity Descriptor of the READ FORMAT CAPACITIES command as follows;
>
> mmc3r10g.pdf Table 210 on page 201
> 01b Unformatted Media.
> The reported value is for the maximum formatted capacity for this media.
For
> DDCD/CD-RW medium, the value reported is the maximum possible when using
Format
> Type 10h.
>
> mmc4r05a.pdf Table 416 on page 347
> 01b Unformatted Media.
> The reported value is for the maximum formatted capacity for this media.
>
> These two descriptions said that the original intention of this field
requests
> to show the possible maximum recordable / readable capacity of a disc.
> Fortunately Data Zone of CD/DVD does not include Spare Area. Then capacity
of
> all Data Zones of CD/DVD disc follows the original intention.
>
> BDA concluded that two different implementations do not cause any trouble
and
> both implementations are reasonable. Therefore BDA would like to request to
MMC
> WG that MMC6 may have a note that explains these two implementations of the
BD-R
> writable drives as follows.
>
> Note: There are two implementations for BD-R writable drive. One
implementation
> reports a value that includes Inner Spare Area. Another implementation
reports a
> value of the maximum user data recordable area. Host may use the third
> descriptor values of Format Type 32h or READ TRACK INFORMATION Command
response
> to obtain a maximum recordable capacity of the Blank BD-R disc.
>
> I personally think that MMC6 may have same table with Table 210 of MMC3 to
> explain this original intention and then explain each medium definitions.
>
> 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  Tue Jan 13 12:43:47 2009
From: lohmeyer at t10.org (John Lohmeyer)
Date: Tue, 13 Jan 2009 13:43:47 -0700
Subject: SAS Protocol WG Minutes posted
Message-ID: <mailman.9.1441607347.22516.t10@sandbox.t10.org>

* From the T10 Reflector (t10 at t10.org), posted by:
* John Lohmeyer <lohmeyer at t10.org>
*
The draft SAS Protocol Working Group minutes are available at:
     http://www.t10.org/cgi-bin/ac.pl?t=d&f=09-029r0.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 lohmeyer at t10.org  Tue Jan 13 12:43:52 2009
From: lohmeyer at t10.org (John Lohmeyer)
Date: Tue, 13 Jan 2009 13:43:52 -0700
Subject: SAT WG Minutes posted
Message-ID: <mailman.10.1441607347.22516.t10@sandbox.t10.org>

* From the T10 Reflector (t10 at t10.org), posted by:
* John Lohmeyer <lohmeyer at t10.org>
*
The draft SAT Working Group minutes are available at:
     http://www.t10.org/cgi-bin/ac.pl?t=d&f=09-030r0.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 Gerry.Houlder at seagate.com  Wed Jan 14 15:38:05 2009
From: Gerry.Houlder at seagate.com (Gerry.Houlder at seagate.com)
Date: Wed, 14 Jan 2009 17:38:05 -0600
Subject: new 08-184 revision posted as 09-054r0
Message-ID: <mailman.11.1441607347.22516.t10@sandbox.t10.org>

* From the T10 Reflector (t10 at t10.org), posted by:
* Gerry.Houlder at seagate.com
*
This proposal includes the changes to 08-184r9 that were requested at the
1/14/09 CAP meeting.
   http://www.t10.org/cgi-bin/ac.pl?t=d&f=09-054r0.pdf
*
* For T10 Reflector information, send a message with
* 'info t10' (no quotes) in the message body to majordomo at t10.org


From pooja.gupta at nsysinc.com  Wed Jan 14 21:15:05 2009
From: pooja.gupta at nsysinc.com (pooja gupta)
Date: Wed, 14 Jan 2009 21:15:05 -0800 (PST)
Subject: STP link layer
Message-ID: <mailman.12.1441607347.22516.t10@sandbox.t10.org>

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

Hi,
I am working on STP protocol in SAS and I have one doubt regarding STP link
layer.
After the SAS phy detects during phy reset sequence that it is connected to a
SATA device,
It issues COMWAKE and after the OOB sequence and speed negotiation are
completed, 
Phy Layer Ready (SATA) message is sent to link layer.
?
Now my query is after this SATA_PHY_READY, does identification sequence
happens?
If yes, then it is said in the protocol that to transmit Identify Address
frame, Phy Layer
Ready (SAS) message is required and does SATA device will have addesses as
specified for
SAS devices?
?
If no, then how exactly does the state machine for Link Layer in case of STP
begin and interface with
SL_CC state machines as these state machines need Enable Disable SAS Link
(Enable) message from SL_IR
State machine which, I suppose do not execute in case of STP?
?
Please clarify my query.
Thanks


From Frederick.Knight at netapp.com  Thu Jan 15 05:13:00 2009
From: Frederick.Knight at netapp.com (Knight, Frederick)
Date: Thu, 15 Jan 2009 08:13:00 -0500
Subject: New 08-149 revision posted
Message-ID: <mailman.13.1441607347.22516.t10@sandbox.t10.org>

* From the T10 Reflector (t10 at t10.org), posted by:
* "Knight, Frederick" <Frederick.Knight at netapp.com>
*
This revision of the thin provisioning proposal includes the final
changes that were agreed on at the 1/14/09 CAP meeting.  All change bars
have been removed.
   http://www.t10.org/cgi-bin/ac.pl?t=d&f=08-149r9.pdf
	Fred Knight
*
* For T10 Reflector information, send a message with
* 'info t10' (no quotes) in the message body to majordomo at t10.org


From billmc37 at ctesc.net  Thu Jan 15 08:02:08 2009
From: billmc37 at ctesc.net (Bill McFerrin)
Date: Thu, 15 Jan 2009 10:02:08 -0600
Subject: SPC-4 Ommission
Message-ID: <mailman.14.1441607347.22516.t10@sandbox.t10.org>

* From the T10 Reflector (t10 at t10.org), posted by:
* Bill McFerrin <billmc37 at ctesc.net>
*
SPC-4, rev 17 refers only to SBC-3 and RBC wrt Power Condition State 
selection using the START STOP UNIT command in 5.10.1. The methodology 
was in MMC-4 and MMC-5.
Yes, we feel slighted.
Cheers,
Bill McFerrin, MMC WG
*
* For T10 Reflector information, send a message with
* 'info t10' (no quotes) in the message body to majordomo at t10.org


From Brian.Day at lsi.com  Thu Jan 15 09:42:03 2009
From: Brian.Day at lsi.com (Day, Brian)
Date: Thu, 15 Jan 2009 10:42:03 -0700
Subject: STP link layer
Message-ID: <mailman.15.1441607347.22516.t10@sandbox.t10.org>

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

Hello Pooja...
No... the identification sequence does not occur once the OOB sequence has
determined that the link is a SATA link.
Since these are then SATA links, there are no SL_IR or SL_CC state machines
either.
So conceptually, as soon as the links exchange the COMWAKEs in your example,
they only contain the functionality as defined by the SATA specifications.
The STP protocol occurs when you have SATA devices connected to SAS
exapanders.  The links connected to the SATA devices only run SATA protocol.
The links connected to other SAS expanders or SAS end devices (i.e.
initiators) are SAS links, that may then establish STP connections.
Note that sections M.14 and M.15 of the SAS spec annex show examples of how
these SAS and SATA links work within the scope of the expander.
Hope this helps!
Brian Day
LSI Corporation
________________________________
From: owner-t10 at t10.org [mailto:owner-t10 at t10.org] On Behalf Of pooja gupta
Sent: Wednesday, January 14, 2009 10:15 PM
To: t10 at t10.org
Subject: STP link layer
Hi,
I am working on STP protocol in SAS and I have one doubt regarding STP link
layer.
After the SAS phy detects during phy reset sequence that it is connected to a
SATA device,
It issues COMWAKE and after the OOB sequence and speed negotiation are
completed,
Phy Layer Ready (SATA) message is sent to link layer.
Now my query is after this SATA_PHY_READY, does identification sequence
happens?
If yes, then it is said in the protocol that to transmit Identify Address
frame, Phy Layer
Ready (SAS) message is required and does SATA device will have addesses as
specified for
SAS devices?
If no, then how exactly does the state machine for Link Layer in case of STP
begin and interface with
SL_CC state machines as these state machines need Enable Disable SAS Link
(Enable) message from SL_IR
State machine which, I suppose do not execute in case of STP?
Please clarify my query.
Thanks
Pooja


From Gerry.Houlder at seagate.com  Thu Jan 15 10:28:18 2009
From: Gerry.Houlder at seagate.com (Gerry.Houlder at seagate.com)
Date: Thu, 15 Jan 2009 12:28:18 -0600
Subject: SPC-4 Ommission
Message-ID: <mailman.16.1441607347.22516.t10@sandbox.t10.org>

* From the T10 Reflector (t10 at t10.org), posted by:
* Gerry.Houlder at seagate.com
*
I think the reason MMC-x was omitted from the SBC-3 reference is that MMC-x
defines its own START STOP UNIT command, therefore it is not dependent on
the SBC-3 description of that command.
This does bring up the point that maybe the Power Condition feature (or
some subset thereof) should be added to MMC-6 if there is a demand for this
feature. I would be willing to work with Bill McFerrin or any other regular
MMC group member if the MMC group wants this.
	     Bill McFerrin						   
	     <billmc37 at ctesc.n						   
	     et>							To 
	     Sent by:		       T10 Reflector <T10 at t10.org>	   
	     owner-t10 at t10.org						cc 
								   Subject 
				       SPC-4 Ommission			   
	     01/15/2009 10:02						   
	     AM 							   
* From the T10 Reflector (t10 at t10.org), posted by:
* Bill McFerrin <billmc37 at ctesc.net>
*
SPC-4, rev 17 refers only to SBC-3 and RBC wrt Power Condition State
selection using the START STOP UNIT command in 5.10.1. The methodology
was in MMC-4 and MMC-5.
Yes, we feel slighted.
Cheers,
Bill McFerrin, MMC WG
*
* For T10 Reflector information, send a message with
* 'info t10' (no quotes) in the message body to majordomo at t10.org
*
* 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  Thu Jan 15 13:06:05 2009
From: Alvin.Cox at seagate.com (Alvin.Cox at seagate.com)
Date: Thu, 15 Jan 2009 15:06:05 -0600
Subject: SAS PHY teleconference scheduled for Feb 12, 2009 10:00 am CST
Message-ID: <mailman.17.1441607347.22516.t10@sandbox.t10.org>

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

Teleconference Feb 12, 2009 10:00 am CST 
USA Toll Free Dial in Number: (877)810-9442 
International Access/Caller Paid Dial In Number: (636)651-3190 
PARTICIPANT CODE: 3243413 
WEBEX information: 
Topic: SAS-2.1 PHY WG 
Date: Thursday, February 12, 2009 
Time: 10:00 am, Central Standard Time (GMT -06:00, Chicago) 
Meeting Number: 826 515 680 
Meeting Password: newsas 
The agenda will be posted prior to the call. 
The initial plan is to discuss electrical testing of active cables. 
Other PHY items posted prior to the teleconference are likely to be 
included in the agenda.
Alvin Cox
Seagate Technology, LLC
Office 405-392-3738
Cell 405-206-4809


From lohmeyer at t10.org  Thu Jan 15 17:29:06 2009
From: lohmeyer at t10.org (John Lohmeyer)
Date: Thu, 15 Jan 2009 18:29:06 -0700
Subject: CAP WG Minutes posted
Message-ID: <mailman.18.1441607347.22516.t10@sandbox.t10.org>

* From the T10 Reflector (t10 at t10.org), posted by:
* John Lohmeyer <lohmeyer at t10.org>
*
The draft CAP Working Group minutes are available at:
     http://www.t10.org/cgi-bin/ac.pl?t=d&f=09-031r0.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 lohmeyer at t10.org  Thu Jan 15 18:17:25 2009
From: lohmeyer at t10.org (John Lohmeyer)
Date: Thu, 15 Jan 2009 19:17:25 -0700
Subject: T10.org Access Control
Message-ID: <mailman.19.1441607347.22516.t10@sandbox.t10.org>

* From the T10 Reflector (t10 at t10.org), posted by:
* John Lohmeyer <lohmeyer at t10.org>
*
I am getting a number of queries about the new Access Control form when
attempting to retrieve a document on www.t10.org. 
T10 members can enter their password in the first part of this form; they do
not need to fill out the bottom part of the form. (If you don't know your
password, use the form at: http://www.t10.org/members/pswdhelp.htm )
People who are not T10 members do not need a password. They need to fill out
the bottom part of the form, including all of the required fields. The box at
the bottom of the form must be checked to signify that you have read the
INCITS Guest Notification. When you click the Submit button, the document you
attempted to access should then be displayed.
The Access Control script stores a small cookie on your machine that makes it
skip displaying the Access Control form thereafter. If you keep seeing the
Access Control form (on the same machine/browser) then you do not have
persistent cookies enabled for t10.org. To enable cookies using MS Internet
Explorer, go to Tools - Internet Options - Privacy - Sites. On Firefox, go to
Tools - Options - Privacy - Cookies. Other browsers have similar controls,
but I do not know exactly where they are.
Unfortunately, the INCITS Policies and Guidelines require these changes on
document access. Please let me know if you continue to have trouble.
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 Alvin.Cox at seagate.com  Fri Jan 16 06:33:34 2009
From: Alvin.Cox at seagate.com (Alvin.Cox at seagate.com)
Date: Fri, 16 Jan 2009 08:33:34 -0600
Subject: SAS PHY WG minutes posted
Message-ID: <mailman.20.1441607347.22516.t10@sandbox.t10.org>

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

The SAS PHY WG minutes are posted at:
   http://www.t10.org/cgi-bin/ac.pl?t=d&f=09-053r0.pdf
Alvin Cox
Seagate Technology, LLC
Office 405-392-3738
Cell 405-206-4809


From roweber at ieee.org  Fri Jan 16 18:48:09 2009
From: roweber at ieee.org (Ralph Weber)
Date: Fri, 16 Jan 2009 20:48:09 -0600
Subject: OSD-2 r05 is available
Message-ID: <mailman.21.1441607347.22516.t10@sandbox.t10.org>

* From the T10 Reflector (t10 at t10.org), posted by:
* Ralph Weber <roweber at ieee.org>
*
OSD-2 r05 (the revision to be forwarded to INCITS for
first public review) is available from:
http://www.t10.org/cgi-bin/ac.pl?t=f&f=osd2r05.pdf
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 lohmeyer at t10.org  Sat Jan 17 23:00:51 2009
From: lohmeyer at t10.org (T10 Document Administrator)
Date: Sun, 18 Jan 2009 00:00:51 -0700
Subject: Recent T10 documents uploaded since 2009/01/11
Message-ID: <mailman.22.1441607348.22516.t10@sandbox.t10.org>

* From the T10 Reflector (t10 at t10.org), posted by:
* T10 Document Administrator <lohmeyer at t10.org>
*
Proposals
---------
SAS: Add low power transceiver options
(by: Gerald Houlder)
T10/08-015r7   Uploaded: 2009/01/13   110028 bytes
http://www.t10.org/cgi-bin/ac.pl?t=d&f=08-015r7.pdf
SAT-3: NV Cache Translation
(by: Mark Overby)
T10/08-018r4   Uploaded: 2009/01/14   112237 bytes
http://www.t10.org/cgi-bin/ac.pl?t=d&f=08-018r4.pdf
SSC-3: Revision 04a Letter Ballot Comment Database
(by: David Peterson)
T10/08-095r6   Uploaded: 2009/01/12   174769 bytes
http://www.t10.org/cgi-bin/ac.pl?t=d&f=08-095r6.pdf
SSC-3: Revision 04a Letter Ballot Comment Database
(by: David Peterson)
T10/08-095r6   Uploaded: 2009/01/12   244224 bytes
http://www.t10.org/cgi-bin/ac.pl?t=d&f=08-095r6.xls
SBC - Thin Provisioning
(by: Frederick Knight)
T10/08-149r9   Uploaded: 2009/01/15   353888 bytes
http://www.t10.org/cgi-bin/ac.pl?t=d&f=08-149r9.pdf
SPL, Low power transceiver options, phy states
(by: Mark Evans)
T10/08-206r4   Uploaded: 2009/01/13   56661 bytes
http://www.t10.org/cgi-bin/ac.pl?t=d&f=08-206r4.pdf
SPL Link Layer Power Management
(by: Brian Day)
T10/08-249r6   Uploaded: 2009/01/12   508957 bytes
http://www.t10.org/cgi-bin/ac.pl?t=d&f=08-249r6.pdf
UAS Clause 4 (Model)
(by: Curtis Stevens)
T10/08-281r4   Uploaded: 2009/01/15   135094 bytes
http://www.t10.org/cgi-bin/ac.pl?t=d&f=08-281r4.pdf
UAS Clause 4 (Model)
(by: Curtis Stevens)
T10/08-281r5   Uploaded: 2009/01/15   135126 bytes
http://www.t10.org/cgi-bin/ac.pl?t=d&f=08-281r5.pdf
SBC-3 Thin Provisioning Commands
(by: Fred Knight, David L. Black)
T10/08-356r5   Uploaded: 2009/01/15   387549 bytes
http://www.t10.org/cgi-bin/ac.pl?t=d&f=08-356r5.pdf
Proposal for SAS 2.1 Specification to Enable Support for Active Cables
(by: Gourgen Oganessyan)
T10/08-358r3   Uploaded: 2009/01/12   266540 bytes
http://www.t10.org/cgi-bin/ac.pl?t=d&f=08-358r3.pdf
SAT-2: Letter ballot comment resolution document
(by: Mark Overby)
T10/08-371r4   Uploaded: 2009/01/12   2801707 bytes
http://www.t10.org/cgi-bin/ac.pl?t=d&f=08-371r4.fdf
SAT-2: Letter ballot comment resolution document
(by: Mark Overby)
T10/08-371r4   Uploaded: 2009/01/12   3897130 bytes
http://www.t10.org/cgi-bin/ac.pl?t=d&f=08-371r4.pdf
SAT-2: Letter ballot comment resolution document
(by: Mark Overby)
T10/08-371r5   Uploaded: 2009/01/14   2816343 bytes
http://www.t10.org/cgi-bin/ac.pl?t=d&f=08-371r5.fdf
SAT-2: Letter ballot comment resolution document
(by: Mark Overby)
T10/08-371r5   Uploaded: 2009/01/14   3897566 bytes
http://www.t10.org/cgi-bin/ac.pl?t=d&f=08-371r5.pdf
Response to T10 Letter Ballot comments on OSD-2
(by: Ralph O. Weber)
T10/08-380r5   Uploaded: 2009/01/16   565719 bytes
http://www.t10.org/cgi-bin/ac.pl?t=d&f=08-380r5.fdf
Response to T10 Letter Ballot comments on OSD-2
(by: Ralph O. Weber)
T10/08-380r5   Uploaded: 2009/01/16   699230 bytes
http://www.t10.org/cgi-bin/ac.pl?t=d&f=08-380r5.pdf
SPC-4: Cache hits and power on statistics
(by: George Penokie)
T10/08-386r3   Uploaded: 2009/01/14   125453 bytes
http://www.t10.org/cgi-bin/ac.pl?t=d&f=08-386r3.pdf
SPC-4: Reporting support for all DIF types
(by: George Penokie)
T10/08-396r3   Uploaded: 2009/01/14   85358 bytes
http://www.t10.org/cgi-bin/ac.pl?t=d&f=08-396r3.pdf
FCP-4: Letter Ballot Comment Database
(by: David Peterson)
T10/08-411r2   Uploaded: 2009/01/12   261439 bytes
http://www.t10.org/cgi-bin/ac.pl?t=d&f=08-411r2.pdf
SBC-3/SPC-4 : Adding a Protection Information Interval
(by: George Penokie)
T10/08-415r4   Uploaded: 2009/01/14   346700 bytes
http://www.t10.org/cgi-bin/ac.pl?t=d&f=08-415r4.pdf
SPL: Power Management Reporting and Control
(by: Brad Besmer)
T10/08-420r2   Uploaded: 2009/01/12   73868 bytes
http://www.t10.org/cgi-bin/ac.pl?t=d&f=08-420r2.pdf
SPC-4: IKEv2-SCSI Authentication
(by: David L. Black)
T10/08-423r4   Uploaded: 2009/01/14   72852 bytes
http://www.t10.org/cgi-bin/ac.pl?t=d&f=08-423r4.pdf
SBC-3 REASSIGN BLOCKS and CbCS
(by: Ralph O. Weber)
T10/09-007r1   Uploaded: 2009/01/15   43811 bytes
http://www.t10.org/cgi-bin/ac.pl?t=d&f=09-007r1.pdf
Project Proposal: SES-3 Project Proposal
(by: Frederick Knight)
T10/09-009r1   Uploaded: 2009/01/15   20776 bytes
http://www.t10.org/cgi-bin/ac.pl?t=d&f=09-009r1.pdf
Tyco Electronics External 8x Mini SAS w/ 4x Modular Capability
(by: Scott Shuey)
T10/09-014r1   Uploaded: 2009/01/13   1110792 bytes
http://www.t10.org/cgi-bin/ac.pl?t=d&f=09-014r1.pdf
SAM5 - QUERY TASK TMF Progress Indicator
(by: Frederick Knight)
T10/09-017r1   Uploaded: 2009/01/14   22899 bytes
http://www.t10.org/cgi-bin/ac.pl?t=d&f=09-017r1.pdf
3M Proposal for a New High Density Mini-SAS System
(by: Charles Staley)
T10/09-027r1   Uploaded: 2009/01/14   331810 bytes
http://www.t10.org/cgi-bin/ac.pl?t=d&f=09-027r1.pdf
Minutes of SAS Protocol Working Group - January 12, 2009
(by: Weber & Lohmeyer)
T10/09-029r0   Uploaded: 2009/01/13   33996 bytes
http://www.t10.org/cgi-bin/ac.pl?t=d&f=09-029r0.htm
Minutes of SAS Protocol Working Group - January 12, 2009
(by: Weber & Lohmeyer)
T10/09-029r0   Uploaded: 2009/01/13   98197 bytes
http://www.t10.org/cgi-bin/ac.pl?t=d&f=09-029r0.pdf
Minutes of SAT Working Group - January 13, 2009
(by: Overby & Lohmeyer)
T10/09-030r0   Uploaded: 2009/01/13   30766 bytes
http://www.t10.org/cgi-bin/ac.pl?t=d&f=09-030r0.htm
Minutes of SAT Working Group - January 13, 2009
(by: Overby & Lohmeyer)
T10/09-030r0   Uploaded: 2009/01/13   91450 bytes
http://www.t10.org/cgi-bin/ac.pl?t=d&f=09-030r0.pdf
Minutes of CAP Working Group - January 14-15, 2009
(by: Weber & Lohmeyer)
T10/09-031r0   Uploaded: 2009/01/15   69033 bytes
http://www.t10.org/cgi-bin/ac.pl?t=d&f=09-031r0.htm
Minutes of CAP Working Group - January 14-15, 2009
(by: Weber & Lohmeyer)
T10/09-031r0   Uploaded: 2009/01/15   161462 bytes
http://www.t10.org/cgi-bin/ac.pl?t=d&f=09-031r0.pdf
SPC-4: EMail comment recieved from Mike Berhan busTRACE
(by: George Penokie)
T10/09-034r1   Uploaded: 2009/01/14   60559 bytes
http://www.t10.org/cgi-bin/ac.pl?t=d&f=09-034r1.pdf
SASWDP v1.8 Evaluation
(by: Kevin Witt)
T10/09-039r0   Uploaded: 2009/01/13   1179707 bytes
http://www.t10.org/cgi-bin/ac.pl?t=d&f=09-039r0.pdf
SPL: COMINIT detection in SP9: SAS_WindowNotSupported state
(by: William Martin)
T10/09-040r0   Uploaded: 2009/01/11   11450 bytes
http://www.t10.org/cgi-bin/ac.pl?t=d&f=09-040r0.pdf
SPL: COMINIT detection in SP9: SAS_WindowNotSupported state
(by: William Martin)
T10/09-040r1   Uploaded: 2009/01/12   11784 bytes
http://www.t10.org/cgi-bin/ac.pl?t=d&f=09-040r1.pdf
Minutes: ADC-3 Minutes for January 12, 2009
(by: Curtis Ballard)
T10/09-041r0   Uploaded: 2009/01/13   32917 bytes
http://www.t10.org/cgi-bin/ac.pl?t=d&f=09-041r0.pdf
Minutes: ADC-3 Minutes for January 12, 2009
(by: Curtis Ballard)
T10/09-041r1   Uploaded: 2009/01/14   32915 bytes
http://www.t10.org/cgi-bin/ac.pl?t=d&f=09-041r1.pdf
FCP-4: Working Group Agenda, January 13, 2009
(by: David Peterson)
T10/09-042r0   Uploaded: 2009/01/12   9151 bytes
http://www.t10.org/cgi-bin/ac.pl?t=d&f=09-042r0.pdf
ADI-2 Working Group Report to Plenary, January 2009
(by: Paul Suhler)
T10/09-043r0   Uploaded: 2009/01/13   66583 bytes
http://www.t10.org/cgi-bin/ac.pl?t=d&f=09-043r0.pdf
SSC-3: Working Group Agenda, January 13, 2009
(by: David Peterson)
T10/09-044r0   Uploaded: 2009/01/13   11224 bytes
http://www.t10.org/cgi-bin/ac.pl?t=d&f=09-044r0.pdf
Minutes SSC-3 January 13 2009
(by: Kevin Butt)
T10/09-046r0   Uploaded: 2009/01/13   58615 bytes
http://www.t10.org/cgi-bin/ac.pl?t=d&f=09-046r0.pdf
SAS-2 SASWDP Public Review Comment Resolution
(by: Harvey Newman)
T10/09-047r0   Uploaded: 2009/01/13   82350 bytes
http://www.t10.org/cgi-bin/ac.pl?t=d&f=09-047r0.pdf
SAS-2 SASWDP Public Review Comment Resolution
(by: Harvey Newman)
T10/09-047r0   Uploaded: 2009/01/13   111866 bytes
http://www.t10.org/cgi-bin/ac.pl?t=d&f=09-047r0.zip
Minutes of FCP-4 Working Group - January 13, 2009
(by: Bob Nixon)
T10/09-048r0   Uploaded: 2009/01/13   19084 bytes
http://www.t10.org/cgi-bin/ac.pl?t=d&f=09-048r0.pdf
SAS-2 SASWDP V1.8 Test Case
(by: Harvey Newman)
T10/09-049r0   Uploaded: 2009/01/13   103970 bytes
http://www.t10.org/cgi-bin/ac.pl?t=d&f=09-049r0.pdf
SAS-2 SASWDP V1.8 Test Case
(by: Harvey Newman)
T10/09-049r0   Uploaded: 2009/01/13   213897 bytes
http://www.t10.org/cgi-bin/ac.pl?t=d&f=09-049r0.zip
IEEE 1619 SISWG Liaison Report for Jan 2009
(by: Matthew V. Ball)
T10/09-050r0   Uploaded: 2009/01/15   73604 bytes
http://www.t10.org/cgi-bin/ac.pl?t=d&f=09-050r0.pdf
SAS-2.1 internal high-density connector proposal SFF-8643
(by: Jay Neer)
T10/09-051r0   Uploaded: 2009/01/14   696803 bytes
http://www.t10.org/cgi-bin/ac.pl?t=d&f=09-051r0.pdf
SAS-2.1 external high-density connector proposal SFF-8644
(by: Jay Neer)
T10/09-052r0   Uploaded: 2009/01/13   1135206 bytes
http://www.t10.org/cgi-bin/ac.pl?t=d&f=09-052r0.pdf
Minutes: SAS PHY Working Group Minutes January 13 2009
(by: Alvin Cox)
T10/09-053r0   Uploaded: 2009/01/15   127581 bytes
http://www.t10.org/cgi-bin/ac.pl?t=d&f=09-053r0.pdf
SPC-4 SBC-3 SPL Adding more idle power options
(by: Gerald Houlder)
T10/09-054r0   Uploaded: 2009/01/14   284307 bytes
http://www.t10.org/cgi-bin/ac.pl?t=d&f=09-054r0.pdf
SPC-4 SBC-3 SPL Adding more idle power options
(by: Gerald Houlder)
T10/09-054r1   Uploaded: 2009/01/15   303173 bytes
http://www.t10.org/cgi-bin/ac.pl?t=d&f=09-054r1.pdf
T13 Liaison Report January 09
(by: Dan Colegrove)
T10/09-055r0   Uploaded: 2009/01/15   4770 bytes
http://www.t10.org/cgi-bin/ac.pl?t=d&f=09-055r0.pdf
Minutes: MMC WG Meeting Minutes, Tuesday 14 January 2009
(by: William McFerrin)
T10/09-056r0   Uploaded: 2009/01/15   25471 bytes
http://www.t10.org/cgi-bin/ac.pl?t=d&f=09-056r0.pdf
STA -T10 Liaison Report - January 15, 2009
(by: Marty Czekalski)
T10/09-057r0   Uploaded: 2009/01/15   179389 bytes
http://www.t10.org/cgi-bin/ac.pl?t=d&f=09-057r0.pdf
Working Drafts
--------------
Object-Based Storage Devices - 2 (OSD-2)
(Editor: Ralph Weber)
 Rev: 04e      Uploaded: 2009/01/16   2495449 bytes
http://www.t10.org/cgi-bin/ac.pl?t=f&f=osd2r04e.pdf
Object-Based Storage Devices - 2 (OSD-2)
(Editor: Ralph Weber)
 Rev: 05       Uploaded: 2009/01/16   2472000 bytes
http://www.t10.org/cgi-bin/ac.pl?t=f&f=osd2r05.pdf
USB Attached SCSI (UAS)
(Editor: Curtis Stevens)
 Rev: 01a      Uploaded: 2009/01/14   286608 bytes
http://www.t10.org/cgi-bin/ac.pl?t=f&f=uas-r01a.pdf
(Report generated on 2009/01/18 at 00:00:51)
*
* For T10 Reflector information, send a message with
* 'info t10' (no quotes) in the message body to majordomo at t10.org


From mfitzpatrick at us.fujitsu.com  Sun Jan 18 07:27:02 2009
From: mfitzpatrick at us.fujitsu.com (Michael Fitzpatrick)
Date: Sun, 18 Jan 2009 07:27:02 -0800
Subject: New group reservation code for March T10 meetings
Message-ID: <mailman.23.1441607348.22516.t10@sandbox.t10.org>

* From the T10 Reflector (t10 at t10.org), posted by:
* Michael Fitzpatrick <mfitzpatrick at us.fujitsu.com>
*
Everyone,
I have checked with the Embassy Suites Hotel Oklahoma City, and the Group 
Name for the March 2009 T10 hotel that was posted on the T10 hotel notice 
was incorrect.	Sorry for posting the wrong group name.
The proper Group Name for the T10 March Hotel is -- FUJ.  If you have 
already made reservations, please make sure that they are under the 
correct Fujitsu group name (FUJ).
The hotel is 2.5 miles due north on the main street (S. Meridian Ave) 
coming out of the OKC Airport.	There are several restaurants within 
walking distance of the hotel.
Any questions, please let me know.
Mike Fitzpatrick
Fujitsu
Cell phone  (405) 820-5809
Email	    mfitzpatrick at us.fujitsu.com
*
* For T10 Reflector information, send a message with
* 'info t10' (no quotes) in the message body to majordomo at t10.org


From swilson at Brocade.COM  Mon Jan 19 20:57:16 2009
From: swilson at Brocade.COM (Steve Wilson)
Date: Mon, 19 Jan 2009 20:57:16 -0800
Subject: [T11.3] Sad News
Message-ID: <mailman.24.1441607348.22516.t10@sandbox.t10.org>

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

All,
I am extremely saddened to inform you that Bob Snively passed away last
Saturday morning. Bob's contributions to T10, T11, and the storage
industry in general have had, and continue to have far reaching impact
on all of us and our respective companies. Bob will be greatly missed
both as a friend and as a colleague.
Bob's family has asked me to let you know that in lieu of a service
there will be a Celebration of Life in honor of Bob this April. As
details become available I will forward those on to you. 
Also, Bob's family has requested that no flowers be sent to their home.
Instead they have requested that we provide any stories or anecdotes
about Bob so that they can be included in a scrapbook for his
grandchildren. I will provide an email address to you over the next few
days where these may be sent.
If you have any questions please feel free to contact me.
Sincerely,
Steven Wilson
Director, Technology and Standards
Brocade
Phone: 408-333-8128
Cell: 408-307-2149
email: swilson at brocade.com


From roweber at IEEE.org  Tue Jan 20 08:01:19 2009
From: roweber at IEEE.org (Ralph Weber)
Date: Tue, 20 Jan 2009 10:01:19 -0600
Subject: Late Letter Ballot comment for FCP-4
Message-ID: <mailman.25.1441607348.22516.t10@sandbox.t10.org>

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

I wish to add the following comment to the FCP-4 Letter Ballot database.
----
Comment:
FCP-4 should be dedicated to Bob Snively.
Justification:
Edited the original FCP as well as FCP-2. Many of the concepts in FCP
can be traced to Bob's initiative.
Adding an FCP-4 dedication to Bob is fully consistent with T10 precedents
(e.g., Bill Spence in SPI and Gene Milligan in SPI-4 and SBC-2).
All the best,
.Ralph
-------- Original Message --------
Subject:	[T11.3] Sad News
Date:	Mon, 19 Jan 2009 20:57:16 -0800
From:	Steve Wilson <swilson at Brocade.COM>
To:	T11_3 <t11_3 at t11.org>, <t11_2 at t11.org>, <t10 at t10.org>
CC:	Kumar Malavalli <kumar at vkrm.com>, Steve Wilson <swilson at Brocade.COM>
All,
I am extremely saddened to inform you that Bob Snively passed away last 
Saturday morning. Bob's contributions to T10, T11, and the storage 
industry in general have had, and continue to have far reaching impact 
on all of us and our respective companies. Bob will be greatly missed 
both as a friend and as a colleague.
Bob's family has asked me to let you know that in lieu of a service 
there will be a Celebration of Life in honor of Bob this April. As 
details become available I will forward those on to you.
Also, Bob's family has requested that no flowers be sent to their home. 
Instead they have requested that we provide any stories or anecdotes 
about Bob so that they can be included in a scrapbook for his 
grandchildren. I will provide an email address to you over the next few 
days where these may be sent.
If you have any questions please feel free to contact me.
Sincerely,
//Steven Wilson//
//Director, Technology and Standards//
//Brocade//
//Phone: 408-333-8128//
//Cell: 408-307-2149//
//email: swilson at brocade.com//


From dpeterso at Brocade.COM  Tue Jan 20 08:50:31 2009
From: dpeterso at Brocade.COM (David Peterson)
Date: Tue, 20 Jan 2009 09:50:31 -0700
Subject: Late Letter Ballot comment for FCP-4
Message-ID: <mailman.26.1441607348.22516.t10@sandbox.t10.org>

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

Agree and already done...thanks...Dave
________________________________
From: owner-t10 at t10.org [mailto:owner-t10 at t10.org] On Behalf Of Ralph
Weber
Sent: Tuesday, January 20, 2009 10:01 AM
To: 't10 at t10.org'
Subject: Late Letter Ballot comment for FCP-4
I wish to add the following comment to the FCP-4 Letter Ballot database.
----
Comment:
FCP-4 should be dedicated to Bob Snively.
Justification:
Edited the original FCP as well as FCP-2. Many of the concepts in FCP 
can be traced to Bob's initiative.
Adding an FCP-4 dedication to Bob is fully consistent with T10
precedents 
(e.g., Bill Spence in SPI and Gene Milligan in SPI-4 and SBC-2).
All the best,
.Ralph
-------- Original Message -------- 
Subject:	[T11.3] Sad News	
Date:	Mon, 19 Jan 2009 20:57:16 -0800 
From:	Steve Wilson <swilson at Brocade.COM> 
To:	T11_3 <t11_3 at t11.org> <mailto:t11_3 at t11.org> , <t11_2 at t11.org>
<mailto:t11_2 at t11.org> , <t10 at t10.org> <mailto:t10 at t10.org>	
CC:	Kumar Malavalli <kumar at vkrm.com>  , Steve
Wilson <swilson at Brocade.COM> 	
All,
I am extremely saddened to inform you that Bob Snively passed away last
Saturday morning. Bob's contributions to T10, T11, and the storage
industry in general have had, and continue to have far reaching impact
on all of us and our respective companies. Bob will be greatly missed
both as a friend and as a colleague.
Bob's family has asked me to let you know that in lieu of a service
there will be a Celebration of Life in honor of Bob this April. As
details become available I will forward those on to you. 
Also, Bob's family has requested that no flowers be sent to their home.
Instead they have requested that we provide any stories or anecdotes
about Bob so that they can be included in a scrapbook for his
grandchildren. I will provide an email address to you over the next few
days where these may be sent.
If you have any questions please feel free to contact me.
Sincerely,
Steven Wilson
Director, Technology and Standards
Brocade
Phone: 408-333-8128
Cell: 408-307-2149
email: swilson at brocade.com


From swilson at Brocade.COM  Tue Jan 20 09:28:47 2009
From: swilson at Brocade.COM (Steve Wilson)
Date: Tue, 20 Jan 2009 10:28:47 -0700
Subject: [T11.3] Sad News
Message-ID: <mailman.27.1441607348.22516.t10@sandbox.t10.org>

* From the T10 Reflector (t10 at t10.org), posted by:
* Steve Wilson <swilson at Brocade.COM> (by way of John Lohmeyer)
*
All,
I am extremely saddened to inform you that Bob Snively passed away last
Saturday morning. Bob?s contributions to T10, T11, and the storage industry
in general have had, and continue to have far reaching impact on all of us
and our respective companies. Bob will be greatly missed both as a friend and
as a colleague.
Bob?s family has asked me to let you know that in lieu of a service there
will be a Celebration of Life in honor of Bob this April. As details become
available I will forward those on to you. 
Also, Bob?s family has requested that no flowers be sent to their home.
Instead they have requested that we provide any stories or anecdotes about
Bob so that they can be included in a scrapbook for his grandchildren. I will
provide an email address to you over the next few days where these may be
sent.
If you have any questions please feel free to contact me.
Sincerely,
Steven Wilson
Director, Technology and Standards
Brocade
Phone: 408-333-8128
Cell: 408-307-2149
email: swilson at brocade.com
*
* For T10 Reflector information, send a message with
* 'info t10' (no quotes) in the message body to majordomo at t10.org


From john.lohmeyer at lsil.com  Tue Jan 20 08:59:48 2009
From: john.lohmeyer at lsil.com (T10 Reflector Admin)
Date: Tue, 20 Jan 2009 09:59:48 -0700
Subject: BOUNCE t10@t10.org:    Non-member submission from ["Steve
Message-ID: <mailman.28.1441607348.22516.t10@sandbox.t10.org>

* From the T10 Reflector (t10 at t10.org), posted by:
* T10 Reflector Admin <john.lohmeyer at lsil.com> (by way of John Lohmeyer
<john.lohmeyer at lsi.com>)
*
Subject: Sad News
Date: Mon, 19 Jan 2009 20:57:16 -0800
From: "Steve Wilson" <swilson at Brocade.COM>
To: "T11_3" <t11_3 at t11.org>, <t11_2 at t11.org>, <t10 at t10.org>
Cc: "Steve Wilson" <swilson at Brocade.COM>, "Kumar Malavalli" <kumar at vkrm.com>
All,
I am extremely saddened to inform you that Bob Snively passed away last
Saturday morning. Bob?s contributions to T10, T11, and the storage industry
in general have had, and continue to have far reaching impact on all of us
and our respective companies. Bob will be greatly missed both as a friend and
as a colleague.
Bob?s family has asked me to let you know that in lieu of a service there
will be a Celebration of Life in honor of Bob this April. As details become
available I will forward those on to you. 
Also, Bob?s family has requested that no flowers be sent to their home.
Instead they have requested that we provide any stories or anecdotes about
Bob so that they can be included in a scrapbook for his grandchildren. I will
provide an email address to you over the next few days where these may be
sent.
If you have any questions please feel free to contact me.
Sincerely,
Steven Wilson
Director, Technology and Standards
Brocade
Phone: 408-333-8128
Cell: 408-307-2149
email: swilson at brocade.com
*
* 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  Tue Jan 20 11:59:04 2009
From: lohmeyer at t10.org (John Lohmeyer)
Date: Tue, 20 Jan 2009 12:59:04 -0700
Subject: Sad News
Message-ID: <mailman.29.1441607348.22516.t10@sandbox.t10.org>

* From the T10 Reflector (t10 at t10.org), posted by:
* John Lohmeyer <lohmeyer at t10.org>
*
We'll all miss Bob a lot. His obituary is available at:

http://www.legacy.com/mercurynews/DeathNotices.asp?Page=LifeStory&PersonID=123052306

John
At 1/20/2009 10:28 AM, Steve Wilson wrote:
>* From the T10 Reflector (t10 at t10.org), posted by:
>* Steve Wilson <swilson at Brocade.COM> (by way of John Lohmeyer)
>*
>All,
>
>I am extremely saddened to inform you that Bob Snively passed away last
Saturday morning. Bob?s contributions to T10, T11, and the storage industry
in general have had, and continue to have far reaching impact on all of us
and our respective companies. Bob will be greatly missed both as a friend and
as a colleague.
>
>Bob?s family has asked me to let you know that in lieu of a service there
will be a Celebration of Life in honor of Bob this April. As details become
available I will forward those on to you.
>
>Also, Bob?s family has requested that no flowers be sent to their home.
Instead they have requested that we provide any stories or anecdotes about
Bob so that they can be included in a scrapbook for his grandchildren. I will
provide an email address to you over the next few days where these may be
sent.
>
>If you have any questions please feel free to contact me.
>
>Sincerely,
>
>Steven Wilson
>Director, Technology and Standards
>Brocade
>Phone: 408-333-8128
>Cell: 408-307-2149
>email: swilson at brocade.com
>
>
>
>*
>* For T10 Reflector information, send a message with
>* 'info t10' (no quotes) in the message body to majordomo at t10.org
--
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 Bob.Nixon at emulex.com  Tue Jan 20 23:44:48 2009
From: Bob.Nixon at emulex.com (Bob.Nixon at emulex.com)
Date: Tue, 20 Jan 2009 23:44:48 -0800
Subject: FCP-4: revised minutes for January 09
Message-ID: <mailman.30.1441607348.22516.t10@sandbox.t10.org>

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

I accidentally posted the wrong document as 09-048r0, which should have been
the minutes of the 13 January 09 FCP-4 meeting. I have posted the correct
minutes document as 09-048r1.
Sorry for the resulting entertainment.
-	   bob


From Bill.Martin at emulex.com  Wed Jan 21 14:46:02 2009
From: Bill.Martin at emulex.com (Bill.Martin at emulex.com)
Date: Wed, 21 Jan 2009 14:46:02 -0800
Subject: SPC-4 question on disconnect-reconnect mode page parameter
Message-ID: <mailman.31.1441607348.22516.t10@sandbox.t10.org>

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

In looking at the disconnect-reconnect mode page in SPC4r17, the definition
for the MAXIMUM BURST SIZE is:
The MAXIMUM BURST SIZE field indicates the maximum amount of data that the
target port shall transfer during a
single data transfer operation. This value is expressed in increments of 512
bytes (i.e., a value of one means 512
bytes, two means 1 024 bytes, etc.). The relationship, if any, between data
transfer operations and interconnect
tenancies is defined in the individual SCSI transport protocol standards. A
value of zero specifies there is no limit
on the amount of data transferred per data transfer operation.
This works for devices that formatted for data in multiples of 512 bytes per
block; however, this does not map well for devices that formatted for
Protection information and the block size is 520 bytes.  I understand that
the data transfer length can be easily compared to number of 512 byte blocks;
however, if you want to have a max burst size of 32 blocks that are 520 bytes
each then this field does not easily map to the number that you want because
33 would map to 32.49 520 byte blocks.	Was there any thought about tying
this to the block size that a storage device was formatted for?
Thanks,
Bill Martin
Emulex
Office of Technology
Industry Standards
916 772-3658
916 765-6875 (Cell)
bill.martin at emulex.com


From kdbutt at us.ibm.com  Wed Jan 21 15:50:32 2009
From: kdbutt at us.ibm.com (Kevin D Butt)
Date: Wed, 21 Jan 2009 16:50:32 -0700
Subject: SPC-4 question on disconnect-reconnect mode page parameter
Message-ID: <mailman.32.1441607348.22516.t10@sandbox.t10.org>

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

Bill,
Maximum burst size is just that, the maximum burst size.  You will need to 
report one 512 byte increment higher but only transfer the 520 bytes.
Kevin D. Butt
SCSI & Fibre Channel Architect, Tape Firmware
MS 6TYA, 9000 S. Rita Rd., Tucson, AZ 85744
Tel: 520-799-5280
Fax: 520-799-2723 (T/L:321)
Email address: kdbutt at us.ibm.com
http://www-03.ibm.com/servers/storage/ 
From:
Bill.Martin at emulex.com
To:
<t10 at t10.org>
Cc:
<Narayan.Ayalasomayajula at emulex.com>
Date:
01/21/2009 04:35 PM
Subject:
SPC-4 question on disconnect-reconnect mode page parameter
In looking at the disconnect-reconnect mode page in SPC4r17, the 
definition for the MAXIMUM BURST SIZE is:
The MAXIMUM BURST SIZE field indicates the maximum amount of data that the 
target port shall transfer during a
single data transfer operation. This value is expressed in increments of 
512 bytes (i.e., a value of one means 512
bytes, two means 1 024 bytes, etc.). The relationship, if any, between 
data transfer operations and interconnect
tenancies is defined in the individual SCSI transport protocol standards. 
A value of zero specifies there is no limit
on the amount of data transferred per data transfer operation.
This works for devices that formatted for data in multiples of 512 bytes 
per block; however, this does not map well for devices that formatted for 
Protection information and the block size is 520 bytes.  I understand that 
the data transfer length can be easily compared to number of 512 byte 
blocks; however, if you want to have a max burst size of 32 blocks that 
are 520 bytes each then this field does not easily map to the number that 
you want because 33 would map to 32.49 520 byte blocks.  Was there any 
thought about tying this to the block size that a storage device was 
formatted for?
Thanks,
Bill Martin
Emulex
Office of Technology
Industry Standards
916 772-3658
916 765-6875 (Cell)
bill.martin at emulex.com


From Paul.Suhler at Quantum.Com  Thu Jan 22 08:24:02 2009
From: Paul.Suhler at Quantum.Com (Paul Suhler)
Date: Thu, 22 Jan 2009 09:24:02 -0700
Subject: Next Revision of iADT Proposal Posted (08-409)
Message-ID: <mailman.33.1441607348.22516.t10@sandbox.t10.org>

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

Hi, everyone.
The following files are now available on the T10 website:
iADT with change bars relative to r4, which was reviewed in the 12
January meeting:
http://www.t10.org/cgi-bin/ac.pl?t=d&f=08-409r5.pdf
Unfortunately, not all of the changes made it into the PDF, so it's
better to use the Word file with change tracking enabled:
http://www.t10.org/cgi-bin/ac.pl?t=d&f=08-409r5.doc
The proposal with all changes accepted (i.e., no change bars) is a new
rev number:
http://www.t10.org/cgi-bin/ac.pl?t=d&f=08-409r6.pdf
I will send an announcement today for the 28 January teleconference.
Thanks,
Paul
___________________________________
Paul A. Suhler | Firmware Engineer | Quantum Corporation | Office:
949.856.7748 | paul.suhler at quantum.com 
___________________________________
Disregard the following Quantum privacy notice.  The information in this
message may be shared with any individual or organization without
restriction.


From Paul.Suhler at Quantum.Com  Thu Jan 22 10:24:26 2009
From: Paul.Suhler at Quantum.Com (Paul Suhler)
Date: Thu, 22 Jan 2009 11:24:26 -0700
Subject: iADT proposal re-posted (T10/08-409r5)
Message-ID: <mailman.34.1441607348.22516.t10@sandbox.t10.org>

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

I've been able to replace 08-409r0.pdf with one that correctly shows
additions and deletions from r4.  The Word version of the file remains
available.
   http://www.t10.org/cgi-bin/ac.pl?t=d&f=08-409r5.pdf
Thanks,
Paul
___________________________________
Paul A. Suhler | Firmware Engineer | Quantum Corporation | Office:
949.856.7748 | paul.suhler at quantum.com 


From Paul.Suhler at Quantum.Com  Thu Jan 22 11:41:14 2009
From: Paul.Suhler at Quantum.Com (Paul Suhler)
Date: Thu, 22 Jan 2009 12:41:14 -0700
Subject: ADI-2 Working Group Teleconference 28 January 2009
Message-ID: <mailman.35.1441607348.22516.t10@sandbox.t10.org>

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

The ADI-2 working group will conduct a teleconference from 8:00 to 10:00
AM PST on Wednesday, 28 January 2009.  The agenda and contact
information are available at:
http://www.t10.org/ftp/t10/adi-agnd.htm
Thanks,
Paul
___________________________________
Paul A. Suhler | Firmware Engineer | Quantum Corporation | Office:
949.856.7748 | paul.suhler at quantum.com 


From lohmeyer at t10.org  Thu Jan 22 12:19:55 2009
From: lohmeyer at t10.org (John Lohmeyer)
Date: Thu, 22 Jan 2009 13:19:55 -0700
Subject: T10 Plenary minutes posted
Message-ID: <mailman.36.1441607348.22516.t10@sandbox.t10.org>

* From the T10 Reflector (t10 at t10.org), posted by:
* John Lohmeyer <lohmeyer at t10.org>
*
The draft T10 plenary minutes from the January 15, 2009 meeting are available
at:
  http://www.t10.org/cgi-bin/ac.pl?t=d&f=09-032r0.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 Gerry.Houlder at seagate.com  Fri Jan 23 11:01:51 2009
From: Gerry.Houlder at seagate.com (Gerry.Houlder at seagate.com)
Date: Fri, 23 Jan 2009 13:01:51 -0600
Subject: SPC-4 question on disconnect-reconnect mode page parameter
Message-ID: <mailman.37.1441607348.22516.t10@sandbox.t10.org>

* From the T10 Reflector (t10 at t10.org), posted by:
* Gerry.Houlder at seagate.com
*
Most people think of the maximum burst size in terms of how long a system
is willing to dedicate bandwidth to a particular task. The time concept is
easier to keep in focus when it is related to bytes transferred, not a
multiple of logical blocks that can vary in size.
	     Bill.Martin at emule						   
	     x.com							   
	     Sent by:							To 
	     owner-t10 at t10.org	       <t10 at t10.org>			   
									cc 
				       <Narayan.Ayalasomayajula at emulex.com 
				       >				   
	     01/21/2009 04:46					   Subject 
	     PM 		       SPC-4 question on		   
				       disconnect-reconnect mode page	   
				       parameter			   
In looking at the disconnect-reconnect mode page in SPC4r17, the definition
for the MAXIMUM BURST SIZE is:
The MAXIMUM BURST SIZE field indicates the maximum amount of data that the
target port shall transfer during a
single data transfer operation. This value is expressed in increments of
512 bytes (i.e., a value of one means 512
bytes, two means 1 024 bytes, etc.). The relationship, if any, between data
transfer operations and interconnect
tenancies is defined in the individual SCSI transport protocol standards. A
value of zero specifies there is no limit
on the amount of data transferred per data transfer operation.
This works for devices that formatted for data in multiples of 512 bytes
per block; however, this does not map well for devices that formatted for
Protection information and the block size is 520 bytes.  I understand that
the data transfer length can be easily compared to number of 512 byte
blocks; however, if you want to have a max burst size of 32 blocks that are
520 bytes each then this field does not easily map to the number that you
want because 33 would map to 32.49 520 byte blocks.  Was there any thought
about tying this to the block size that a storage device was formatted for?
Thanks,
Bill Martin
Emulex
Office of Technology
Industry Standards
916 772-3658
916 765-6875 (Cell)
bill.martin at emulex.com
*
* 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 Jan 24 14:22:53 2009
From: lohmeyer at t10.org (John Lohmeyer)
Date: Sat, 24 Jan 2009 15:22:53 -0700
Subject: Fwd: INCITS Elects New Chairman/Vice Chairman of Executive
  Board
Message-ID: <mailman.38.1441607348.22516.t10@sandbox.t10.org>

Attachment #1: <a href="http://www.t10.org/cgi-bin/ac.pl?t=r&f=r0901240_incits_new_chair.pdf">incits_new_chair.pdf</a>

For your information. -- John
>From: "Garner, Jennifer" <jgarner at itic.org>
>To: "eb at standards.incits.org" <eb at standards.incits.org>,
>	 "incits-chairs at lyris.itic.org" <incits-chairs at lyris.itic.org>,
>	 "vice-chairs at standards.incits.org"
<vice-chairs at standards.incits.org>,
>	 "irs at standards.incits.org" <irs at standards.incits.org>,
>	 "sc-tags at standards.incits.org" <sc-tags at standards.incits.org>
>Date: Sat, 24 Jan 2009 11:57:21 -0700
>Subject: INCITS Elects New Chairman/Vice Chairman of Executive Board
>
>See attached release.
> 
>***************************************************************
>WASHINGTON, D.C. ? Don Wright, Standards Director for Lexmark International,
has been elected as the new chairman of the InterNational Committee for
Information Technology Standards, or INCITS.  Wright, who has more than 29
years of experience in the field of engineering, marketing, software and
standards development, succeeds Karen Higginbottom of Hewlett-Packard, who
had been chair since 1999.
> 
>Wright said his first challenge will be at the INCITS strategic meeting this
month, where members will explore ways to expand the influence of the
Committee and what additional new areas that INCITS can branch into. INCITS
is the	primary organization for setting technology standards.
> 
>?We should look at new areas for INCITS to go so we can generate new
technical work,? said Wright. ?I hope to work with other committee members to
discuss both expanding what we do and addressing the challenges we face.
Standardization has to remain connected to cutting edge technology.?  Wright
holds a BS and a Masters of Electrical Engineering from the University of
Louisville.
> 
>In addition to Wright, Donald Deutsch, a senior executive at Oracle
Corporation in California, has been elected as the Vice Chairman of the
INCITS Executive Board. Deutsch, a 30-year veteran of information technology,
earned a BS from Miami University and both a doctorate degree and an MBA from
the University of Maryland.
> 
>ABOUT INCITS
>The InterNational Committee for Information Technology Standards - or INCITS
- is the primary U.S. entity dedicated to formulating and promoting the
effective use of standards in the field of Information and Communications
Technologies (ICT). The area of focus for INCITS encompasses storage,
processing, transfer, display, management, organization, and retrieval of
information. The organization has an Executive Board comprised of the leading
companies, government agencies, universities and other institutions devoted
to standardization for information technology. INCITS and the Information
Technology Industry Council (ITI) are jointly accredited by, and operate
under rules approved by, the American National Standards Institute (ANSI).
> 
--
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 lohmeyer at t10.org  Sat Jan 24 23:00:50 2009
From: lohmeyer at t10.org (T10 Document Administrator)
Date: Sun, 25 Jan 2009 00:00:50 -0700
Subject: Recent T10 documents uploaded since 2009/01/18
Message-ID: <mailman.39.1441607348.22516.t10@sandbox.t10.org>

* From the T10 Reflector (t10 at t10.org), posted by:
* T10 Document Administrator <lohmeyer at t10.org>
*
Proposals
---------
ADT-2: Internet ADT (iADT) with change bars
(by: Paul Suhler)
T10/08-409r5   Uploaded: 2009/01/22   2101248 bytes
http://www.t10.org/cgi-bin/ac.pl?t=d&f=08-409r5.doc
ADT-2: Internet ADT (iADT) with change bars
(by: Paul Suhler)
T10/08-409r5   Uploaded: 2009/01/22   439745 bytes
http://www.t10.org/cgi-bin/ac.pl?t=d&f=08-409r5.pdf
ADT-2:	Internet ADT (iADT) -- without change bars
(by: Paul Suhler)
T10/08-409r6   Uploaded: 2009/01/22   383070 bytes
http://www.t10.org/cgi-bin/ac.pl?t=d&f=08-409r6.pdf
SSC-3: Resolution to LB Comment EMC-001 (Multiple SDK support)
(by: Dale LaFollette)
T10/08-410r3   Uploaded: 2009/01/20   97754 bytes
http://www.t10.org/cgi-bin/ac.pl?t=d&f=08-410r3.pdf
Minutes of SAS Protocol Working Group - January 12, 2009
(by: Weber & Lohmeyer)
T10/09-029r1   Uploaded: 2009/01/21   34144 bytes
http://www.t10.org/cgi-bin/ac.pl?t=d&f=09-029r1.htm
Minutes of SAS Protocol Working Group - January 12, 2009
(by: Weber & Lohmeyer)
T10/09-029r1   Uploaded: 2009/01/21   98703 bytes
http://www.t10.org/cgi-bin/ac.pl?t=d&f=09-029r1.pdf
Minutes of SAT Working Group - January 13, 2009
(by: Overby & Lohmeyer)
T10/09-030r1   Uploaded: 2009/01/21   30898 bytes
http://www.t10.org/cgi-bin/ac.pl?t=d&f=09-030r1.htm
Minutes of SAT Working Group - January 13, 2009
(by: Overby & Lohmeyer)
T10/09-030r1   Uploaded: 2009/01/21   91817 bytes
http://www.t10.org/cgi-bin/ac.pl?t=d&f=09-030r1.pdf
Minutes of T10 Plenary Meeting #89 - January 15, 2009
(by: Weber & Lohmeyer)
T10/09-032r0   Uploaded: 2009/01/23   141593 bytes
http://www.t10.org/cgi-bin/ac.pl?t=d&f=09-032r0.htm
Minutes of T10 Plenary Meeting #89 - January 15, 2009
(by: Weber & Lohmeyer)
T10/09-032r0   Uploaded: 2009/01/23   344891 bytes
http://www.t10.org/cgi-bin/ac.pl?t=d&f=09-032r0.pdf
SBC-3, More background scan clean-up
(by: Mark Evans)
T10/09-038r1   Uploaded: 2009/01/22   86606 bytes
http://www.t10.org/cgi-bin/ac.pl?t=d&f=09-038r1.pdf
SAS-2 SASWDP Public Review Comment Resolution
(by: Harvey Newman)
T10/09-047r1   Uploaded: 2009/01/20   83243 bytes
http://www.t10.org/cgi-bin/ac.pl?t=d&f=09-047r1.pdf
Minutes of FCP-4 Working Group - January 13, 2009
(by: Bob Nixon)
T10/09-048r1   Uploaded: 2009/01/21   17408 bytes
http://www.t10.org/cgi-bin/ac.pl?t=d&f=09-048r1.pdf
Agenda for T10 Meeting #90 March 2009
(by: John Lohmeyer)
T10/09-058r0   Uploaded: 2009/01/19   61437 bytes
http://www.t10.org/cgi-bin/ac.pl?t=d&f=09-058r0.pdf
T10 Project Summary - January 2009
(by: John Lohmeyer)
T10/09-059r0   Uploaded: 2009/01/22   34729 bytes
http://www.t10.org/cgi-bin/ac.pl?t=d&f=09-059r0.pdf
Jeopardy Letter for March 2009 meeting
(by: John Lohmeyer)
T10/09-060r0   Uploaded: 2009/01/21   88258 bytes
http://www.t10.org/cgi-bin/ac.pl?t=d&f=09-060r0.pdf
Response to Public Review Comment #1 on BSR INCITS 457-200x (SAS-2)
(by: John Lohmeyer)
T10/09-061r0   Uploaded: 2009/01/22   4225 bytes
http://www.t10.org/cgi-bin/ac.pl?t=d&f=09-061r0.htm
Response to Public Review Comment #1 on BSR INCITS 457-200x (SAS-2)
(by: John Lohmeyer)
T10/09-061r0   Uploaded: 2009/01/22   59357 bytes
http://www.t10.org/cgi-bin/ac.pl?t=d&f=09-061r0.pdf
Working Drafts
--------------
Serial Attached SCSI - 2.1 (SAS-2.1)
(Editor: Alvin Cox)
 Rev: 00       Uploaded: 2009/01/20   2544349 bytes
http://www.t10.org/cgi-bin/ac.pl?t=f&f=sas21-r00.pdf
Serial Attached SCSI - 2.1 (SAS-2.1)
(Editor: Alvin Cox)
 Rev: 00       Uploaded: 2009/01/20   3274097 bytes
http://www.t10.org/cgi-bin/ac.pl?t=f&f=sas21-r00.zip
USB Attached SCSI (UAS)
(Editor: Curtis Stevens)
 Rev: 01b      Uploaded: 2009/01/20   323504 bytes
http://www.t10.org/cgi-bin/ac.pl?t=f&f=uas-r01b.pdf
(Report generated on 2009/01/25 at 00:00:50)
*
* 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 Jan 26 00:29:30 2009
From: keiji_katata at post.pioneer.co.jp (keiji_katata at post.pioneer.co.jp)
Date: Mon, 26 Jan 2009 17:29:30 +0900
Subject: posted commnet_fuji7-8.pdf for an error of FUJI7R111
Message-ID: <mailman.40.1441607348.22516.t10@sandbox.t10.org>

* From the T10 Reflector (t10 at t10.org), posted by:
* keiji_katata at post.pioneer.co.jp
*
Hello all,
An error found on Fuji7 Rev.1.11. So I updated commnet_fuji7-7.pdf and posted
commnet_fuji7-8.pdf on ftp.
 /Mtfuji_7/Spec/commnet_fuji7-8.pdf">ftp.avc-pioneer.com>/Mtfuji_7/Spec/commnet_fuji7-8.pdf
The Disc indicator field value 0101b of "DVD-Download Ver 1.0/2.0" in Table
140
- Comparison of DVD media format on page 295 is wrong. It is 0100b same as
"DVD-Download Rev 1.0".
I'm sorry that I forgot update this table when I updated Table 28 - Disc
Identifier field definition for DVD-Download media on page 101.
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 Frederick.Knight at netapp.com  Mon Jan 26 07:47:04 2009
From: Frederick.Knight at netapp.com (Knight, Frederick)
Date: Mon, 26 Jan 2009 10:47:04 -0500
Subject: SPC-4 question on disconnect-reconnect mode page parameter
Message-ID: <mailman.41.1441607348.22516.t10@sandbox.t10.org>

* From the T10 Reflector (t10 at t10.org), posted by:
* "Knight, Frederick" <Frederick.Knight at netapp.com>
*
My opinion is that this information existed pre-DIF, and was not updated
when protection information was added to SBC.  Yes, time makes more
sense, but the values are already specified as 512-byte block based, not
time based.
So, I would suggest that the proper interpretation is to read the word
"data" as "user data".	The problem is that "user data" is defined in
SBC, not in SPC, but here is the idea:
The MAXIMUM BURST SIZE field indicates the maximum amount of <user> data
that the
target port shall transfer during a single data transfer operation. This
value is expressed in increments of 512 <user data> bytes (i.e., a value
of one means 512 bytes <of user data>, two means 1 024 bytes <of user
data>, etc.). The relationship, if any, between data transfer operations
and interconnect tenancies is defined in the individual SCSI transport
protocol standards. A value of zero specifies there is no limit on the
amount of <user> data transferred per data transfer operation.
The issue of course, is that "user data" is defined in SBC (and relates
to protection information that is defined in SBC), but the above text is
|from SPC (where "user data" is not defined, and there is no concept of
protection information).
Another choice might be to add something in SBC that further clarifies
the SPC text, and more specifically states that the value in that field
represents "user data".  Or, in SBC, you could say:
If protection information is enabled, then this value is expressed in
increments...
If protection information is not enabled, then this value is expressed
in increments...
Either way, it sounds like we'll be seeing a proposal at the next
meeting to suggest how to deal with this issue. 
	Fred Knight
	NetApp
	SAN Standards Technologist
-----Original Message-----
From: Gerry.Houlder at seagate.com [mailto:Gerry.Houlder at seagate.com] 
Sent: Friday, January 23, 2009 2:02 PM
To: t10 at t10.org
Cc: Narayan.Ayalasomayajula at emulex.com
Subject: Re: SPC-4 question on disconnect-reconnect mode page parameter
* From the T10 Reflector (t10 at t10.org), posted by:
* Gerry.Houlder at seagate.com
*
Most people think of the maximum burst size in terms of how long a
system
is willing to dedicate bandwidth to a particular task. The time concept
is
easier to keep in focus when it is related to bytes transferred, not a
multiple of logical blocks that can vary in size.
	     Bill.Martin at emule
	     x.com
	     Sent by:
To 
	     owner-t10 at t10.org	       <t10 at t10.org>
cc 
<Narayan.Ayalasomayajula at emulex.com 
				       >
	     01/21/2009 04:46
Subject 
	     PM 		       SPC-4 question on
				       disconnect-reconnect mode page
				       parameter
In looking at the disconnect-reconnect mode page in SPC4r17, the
definition
for the MAXIMUM BURST SIZE is:
The MAXIMUM BURST SIZE field indicates the maximum amount of data that
the
target port shall transfer during a
single data transfer operation. This value is expressed in increments of
512 bytes (i.e., a value of one means 512
bytes, two means 1 024 bytes, etc.). The relationship, if any, between
data
transfer operations and interconnect
tenancies is defined in the individual SCSI transport protocol
standards. A
value of zero specifies there is no limit
on the amount of data transferred per data transfer operation.
This works for devices that formatted for data in multiples of 512 bytes
per block; however, this does not map well for devices that formatted
for
Protection information and the block size is 520 bytes.  I understand
that
the data transfer length can be easily compared to number of 512 byte
blocks; however, if you want to have a max burst size of 32 blocks that
are
520 bytes each then this field does not easily map to the number that
you
want because 33 would map to 32.49 520 byte blocks.  Was there any
thought
about tying this to the block size that a storage device was formatted
for?
Thanks,
Bill Martin
Emulex
Office of Technology
Industry Standards
916 772-3658
916 765-6875 (Cell)
bill.martin at emulex.com
*
* For T10 Reflector information, send a message with
* 'info t10' (no quotes) in the message body to majordomo at t10.org
*
* For T10 Reflector information, send a message with
* 'info t10' (no quotes) in the message body to majordomo at t10.org


From Bob.Sheffield at lsi.com  Mon Jan 26 08:33:47 2009
From: Bob.Sheffield at lsi.com (Sheffield, Bob)
Date: Mon, 26 Jan 2009 08:33:47 -0800
Subject: SPC-4 question on disconnect-reconnect mode page parameter
Message-ID: <mailman.42.1441607348.22516.t10@sandbox.t10.org>

* From the T10 Reflector (t10 at t10.org), posted by:
* "Sheffield, Bob" <Bob.Sheffield at lsi.com>
*
It's more complicated than that.
I belive MAXIMUM BURST SIZE and FIRST BURST SIZE should be specified the same
way.
FIRST BURST SIZE is also specified in 512-byte increments. The question is,
does the burst size (FIRST or MAXIMUM) have more to do with the blocksize or
the transport. SAS has a maximum frame payload of 1024 bytes, so a FIRST
BURST SIZE set to a value that is a multiple of 2 (times 512) works nicely,
regardless of the underlying blocksize.
Would parameter rounding be a way to deal with this for target devices that
prefer to align bursts on block boundaries with DIF?
Another issue - a device that supports transferring DIF is also required to
support legacy commands (xxPROTECT = 0) that do not transfer DIF fields. Is
the maximum burst size going to be different for one command versus another,
depending on the setting of xxPROTECT?
I think what this means is the burst size is more tightly coupled to the
requirements of the transport rather than the granularity of blocks within
the device. 512 seemed like a reasonable "minimum chunk" for specifying burst
sizes. But maybe both should be specified in bytes? If it's a big enough
issue, then the solution is proably to define a new bit (probably from the
reserved byte 13) to specify that the burst sizes are specified in bytes
rather than bits (or use the entire byte to specify a different value as the
multiplier for burst size, with a value of zero meaning 512).
Bob
-----Original Message-----
From: owner-t10 at t10.org [mailto:owner-t10 at t10.org] On Behalf Of Knight,
Frederick
Sent: Monday, January 26, 2009 8:47 AM
To: Gerry.Houlder at seagate.com; t10 at t10.org
Cc: Narayan.Ayalasomayajula at emulex.com
Subject: RE: SPC-4 question on disconnect-reconnect mode page parameter
* From the T10 Reflector (t10 at t10.org), posted by:
* "Knight, Frederick" <Frederick.Knight at netapp.com>
*
My opinion is that this information existed pre-DIF, and was not updated when
protection information was added to SBC.  Yes, time makes more sense, but the
values are already specified as 512-byte block based, not time based.
So, I would suggest that the proper interpretation is to read the word "data"
as "user data".  The problem is that "user data" is defined in SBC, not in
SPC, but here is the idea:
The MAXIMUM BURST SIZE field indicates the maximum amount of <user> data that
the target port shall transfer during a single data transfer operation. This
value is expressed in increments of 512 <user data> bytes (i.e., a value of
one means 512 bytes <of user data>, two means 1 024 bytes <of user
data>, etc.). The relationship, if any, between data transfer operations
and interconnect tenancies is defined in the individual SCSI transport
protocol standards. A value of zero specifies there is no limit on the amount
of <user> data transferred per data transfer operation.
The issue of course, is that "user data" is defined in SBC (and relates to
protection information that is defined in SBC), but the above text is from
SPC (where "user data" is not defined, and there is no concept of protection
information).
Another choice might be to add something in SBC that further clarifies the
SPC text, and more specifically states that the value in that field
represents "user data".  Or, in SBC, you could say:
If protection information is enabled, then this value is expressed in
increments...
If protection information is not enabled, then this value is expressed in
increments...
Either way, it sounds like we'll be seeing a proposal at the next meeting to
suggest how to deal with this issue. 
	Fred Knight
	NetApp
	SAN Standards Technologist
-----Original Message-----
From: Gerry.Houlder at seagate.com [mailto:Gerry.Houlder at seagate.com]
Sent: Friday, January 23, 2009 2:02 PM
To: t10 at t10.org
Cc: Narayan.Ayalasomayajula at emulex.com
Subject: Re: SPC-4 question on disconnect-reconnect mode page parameter
* From the T10 Reflector (t10 at t10.org), posted by:
* Gerry.Houlder at seagate.com
*
Most people think of the maximum burst size in terms of how long a system is
willing to dedicate bandwidth to a particular task. The time concept is
easier to keep in focus when it is related to bytes transferred, not a
multiple of logical blocks that can vary in size.
	     Bill.Martin at emule
	     x.com
	     Sent by:
To 
	     owner-t10 at t10.org	       <t10 at t10.org>
cc 
<Narayan.Ayalasomayajula at emulex.com 
				       >
	     01/21/2009 04:46
Subject 
	     PM 		       SPC-4 question on
				       disconnect-reconnect mode page
				       parameter
In looking at the disconnect-reconnect mode page in SPC4r17, the definition
for the MAXIMUM BURST SIZE is:
The MAXIMUM BURST SIZE field indicates the maximum amount of data that the
target port shall transfer during a single data transfer operation. This
value is expressed in increments of
512 bytes (i.e., a value of one means 512 bytes, two means 1 024 bytes,
etc.). The relationship, if any, between data transfer operations and
interconnect tenancies is defined in the individual SCSI transport protocol
standards. A value of zero specifies there is no limit on the amount of data
transferred per data transfer operation.
This works for devices that formatted for data in multiples of 512 bytes per
block; however, this does not map well for devices that formatted for
Protection information and the block size is 520 bytes.  I understand that
the data transfer length can be easily compared to number of 512 byte blocks;
however, if you want to have a max burst size of 32 blocks that are 520 bytes
each then this field does not easily map to the number that you want because
33 would map to 32.49 520 byte blocks.	Was there any thought about tying
this to the block size that a storage device was formatted for?
Thanks,
Bill Martin
Emulex
Office of Technology
Industry Standards
916 772-3658
916 765-6875 (Cell)
bill.martin at emulex.com
*
* For T10 Reflector information, send a message with
* 'info t10' (no quotes) in the message body to majordomo at t10.org
*
* For T10 Reflector information, send a message with
* 'info t10' (no quotes) in the message body to majordomo at t10.org
*
* 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 Jan 26 09:52:02 2009
From: kdbutt at us.ibm.com (Kevin D Butt)
Date: Mon, 26 Jan 2009 10:52:02 -0700
Subject: SPC-4 question on disconnect-reconnect mode page parameter
Message-ID: <mailman.43.1441607348.22516.t10@sandbox.t10.org>

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

These fields are indeed related to what is needed in the transport. 
Separate the layers and focus only on the transport please.
This is what you would use to limit your maximum frame size you would 
allow in your transport.
Kevin D. Butt
SCSI & Fibre Channel Architect, Tape Firmware
MS 6TYA, 9000 S. Rita Rd., Tucson, AZ 85744
Tel: 520-799-5280
Fax: 520-799-2723 (T/L:321)
Email address: kdbutt at us.ibm.com
http://www-03.ibm.com/servers/storage/ 
From:
"Sheffield, Bob" <Bob.Sheffield at lsi.com>
To:
"Knight, Frederick" <Frederick.Knight at netapp.com>, 
"Gerry.Houlder at seagate.com" <Gerry.Houlder at seagate.com>, "t10 at t10.org" 
<t10 at t10.org>
Cc:
"Narayan.Ayalasomayajula at emulex.com" <Narayan.Ayalasomayajula at emulex.com>
Date:
01/26/2009 10:20 AM
Subject:
RE: SPC-4 question on disconnect-reconnect mode page parameter
* From the T10 Reflector (t10 at t10.org), posted by:
* "Sheffield, Bob" <Bob.Sheffield at lsi.com>
*
It's more complicated than that.
I belive MAXIMUM BURST SIZE and FIRST BURST SIZE should be specified the 
same way.
FIRST BURST SIZE is also specified in 512-byte increments. The question 
is, does the burst size (FIRST or MAXIMUM) have more to do with the 
blocksize or the transport. SAS has a maximum frame payload of 1024 bytes, 
so a FIRST BURST SIZE set to a value that is a multiple of 2 (times 512) 
works nicely, regardless of the underlying blocksize.
Would parameter rounding be a way to deal with this for target devices 
that prefer to align bursts on block boundaries with DIF?
Another issue - a device that supports transferring DIF is also required 
to support legacy commands (xxPROTECT = 0) that do not transfer DIF 
fields. Is the maximum burst size going to be different for one command 
versus another, depending on the setting of xxPROTECT?
I think what this means is the burst size is more tightly coupled to the 
requirements of the transport rather than the granularity of blocks within 
the device. 512 seemed like a reasonable "minimum chunk" for specifying 
burst sizes. But maybe both should be specified in bytes? If it's a big 
enough issue, then the solution is proably to define a new bit (probably 
|from the reserved byte 13) to specify that the burst sizes are specified 
in bytes rather than bits (or use the entire byte to specify a different 
value as the multiplier for burst size, with a value of zero meaning 512).
Bob
-----Original Message-----
From: owner-t10 at t10.org [mailto:owner-t10 at t10.org] On Behalf Of Knight, 
Frederick
Sent: Monday, January 26, 2009 8:47 AM
To: Gerry.Houlder at seagate.com; t10 at t10.org
Cc: Narayan.Ayalasomayajula at emulex.com
Subject: RE: SPC-4 question on disconnect-reconnect mode page parameter
* From the T10 Reflector (t10 at t10.org), posted by:
* "Knight, Frederick" <Frederick.Knight at netapp.com>
*
My opinion is that this information existed pre-DIF, and was not updated 
when protection information was added to SBC.  Yes, time makes more sense, 
but the values are already specified as 512-byte block based, not time 
based.
So, I would suggest that the proper interpretation is to read the word 
"data" as "user data".	The problem is that "user data" is defined in SBC, 
not in SPC, but here is the idea:
The MAXIMUM BURST SIZE field indicates the maximum amount of <user> data 
that the target port shall transfer during a single data transfer 
operation. This value is expressed in increments of 512 <user data> bytes 
(i.e., a value of one means 512 bytes <of user data>, two means 1 024 
bytes <of user
data>, etc.). The relationship, if any, between data transfer operations
and interconnect tenancies is defined in the individual SCSI transport 
protocol standards. A value of zero specifies there is no limit on the 
amount of <user> data transferred per data transfer operation.
The issue of course, is that "user data" is defined in SBC (and relates to 
protection information that is defined in SBC), but the above text is from 
SPC (where "user data" is not defined, and there is no concept of 
protection information).
Another choice might be to add something in SBC that further clarifies the 
SPC text, and more specifically states that the value in that field 
represents "user data".  Or, in SBC, you could say:
If protection information is enabled, then this value is expressed in 
increments...
If protection information is not enabled, then this value is expressed in 
increments...
Either way, it sounds like we'll be seeing a proposal at the next meeting 
to suggest how to deal with this issue. 
		 Fred Knight
		 NetApp
		 SAN Standards Technologist
-----Original Message-----
From: Gerry.Houlder at seagate.com [mailto:Gerry.Houlder at seagate.com]
Sent: Friday, January 23, 2009 2:02 PM
To: t10 at t10.org
Cc: Narayan.Ayalasomayajula at emulex.com
Subject: Re: SPC-4 question on disconnect-reconnect mode page parameter
* From the T10 Reflector (t10 at t10.org), posted by:
* Gerry.Houlder at seagate.com
*
Most people think of the maximum burst size in terms of how long a system 
is willing to dedicate bandwidth to a particular task. The time concept is 
easier to keep in focus when it is related to bytes transferred, not a 
multiple of logical blocks that can vary in size.
	     Bill.Martin at emule
	     x.com
	     Sent by:
To 
	     owner-t10 at t10.org	       <t10 at t10.org>
cc 
<Narayan.Ayalasomayajula at emulex.com 
				       >
	     01/21/2009 04:46
Subject 
	     PM 		       SPC-4 question on
				       disconnect-reconnect mode page
				       parameter
In looking at the disconnect-reconnect mode page in SPC4r17, the 
definition for the MAXIMUM BURST SIZE is:
The MAXIMUM BURST SIZE field indicates the maximum amount of data that the 
target port shall transfer during a single data transfer operation. This 
value is expressed in increments of
512 bytes (i.e., a value of one means 512 bytes, two means 1 024 bytes, 
etc.). The relationship, if any, between data transfer operations and 
interconnect tenancies is defined in the individual SCSI transport 
protocol standards. A value of zero specifies there is no limit on the 
amount of data transferred per data transfer operation.
This works for devices that formatted for data in multiples of 512 bytes 
per block; however, this does not map well for devices that formatted for 
Protection information and the block size is 520 bytes.  I understand that 
the data transfer length can be easily compared to number of 512 byte 
blocks; however, if you want to have a max burst size of 32 blocks that 
are 520 bytes each then this field does not easily map to the number that 
you want because 33 would map to 32.49 520 byte blocks.  Was there any 
thought about tying this to the block size that a storage device was 
formatted for?
Thanks,
Bill Martin
Emulex
Office of Technology
Industry Standards
916 772-3658
916 765-6875 (Cell)
bill.martin at emulex.com
*
* For T10 Reflector information, send a message with
* 'info t10' (no quotes) in the message body to majordomo at t10.org
*
* For T10 Reflector information, send a message with
* 'info t10' (no quotes) in the message body to majordomo at t10.org
*
* For T10 Reflector information, send a message with
* 'info t10' (no quotes) in the message body to majordomo at t10.org


From Bob.Sheffield at lsi.com  Mon Jan 26 10:13:47 2009
From: Bob.Sheffield at lsi.com (Sheffield, Bob)
Date: Mon, 26 Jan 2009 11:13:47 -0700
Subject: SPC-4 question on disconnect-reconnect mode page parameter
Message-ID: <mailman.44.1441607348.22516.t10@sandbox.t10.org>

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

Sorry for the technical errors in my earlier posting.
Each 512-byte burst increment counts bytes of frame payload, whether it's a
DIF-enabled READ/WRITE, a legacy READ/WRITE, or some other command like MODE
SENSE or WRITE BUFFER. DIF (if present) is part of the frame payload (the
transport layer doesn't know if DIF is present or not), and so DIF counts
towards the 512 bytes of the burst increment it falls within. So, for
example, if the device is formatted to 512+DIF (520 total per block), and a
WRITE(10) command specifies WRPROTECT = 001b (transfer DIF), the first burst
increment transferred contains 512 bytes for the first block specified, and
the second burst increment contains the 8-bytes of DIF for the first block,
and the first 504 bytes of the second block, etc...
FIRST BURST SIZE and MAXIMUM BURST SIZE should be specified the same way.
Implementations that support first burst size are no doubt implemented so as
to count bytes of frame payload (which includes DIF) as part of the burst
count. If the standard were modified to force larger (frame payload) bursts
when DIF is present, it would likely break some existing implementations, so
that is not a reasonable path to take.
Bob Sheffield
Engenio Storage Group
MegaRAID Architecture
LSI Corporation

www.lsi.com<<a href="http://www.lsi.com/&gt">http://www.lsi.com/&gt;
________________________________
From: Kevin D Butt [mailto:kdbutt at us.ibm.com]
Sent: Monday, January 26, 2009 10:52 AM
To: Sheffield, Bob
Cc: Knight, Frederick; Gerry.Houlder at seagate.com;
Narayan.Ayalasomayajula at emulex.com; owner-t10 at t10.org; t10 at t10.org
Subject: RE: SPC-4 question on disconnect-reconnect mode page parameter
These fields are indeed related to what is needed in the transport.  Separate
the layers and focus only on the transport please.
This is what you would use to limit your maximum frame size you would allow
in your transport.
Kevin D. Butt
SCSI & Fibre Channel Architect, Tape Firmware
MS 6TYA, 9000 S. Rita Rd., Tucson, AZ 85744
Tel: 520-799-5280
Fax: 520-799-2723 (T/L:321)
Email address: kdbutt at us.ibm.com
http://www-03.ibm.com/servers/storage/
From:	"Sheffield, Bob" <Bob.Sheffield at lsi.com>
To:	"Knight, Frederick" <Frederick.Knight at netapp.com>,
"Gerry.Houlder at seagate.com" <Gerry.Houlder at seagate.com>, "t10 at t10.org"
<t10 at t10.org>
Cc:	"Narayan.Ayalasomayajula at emulex.com"
<Narayan.Ayalasomayajula at emulex.com>
Date:	01/26/2009 10:20 AM
Subject:	RE: SPC-4 question on disconnect-reconnect mode page
parameter
________________________________
* From the T10 Reflector (t10 at t10.org), posted by:
* "Sheffield, Bob" <Bob.Sheffield at lsi.com>
*
It's more complicated than that.
I belive MAXIMUM BURST SIZE and FIRST BURST SIZE should be specified the same
way.
FIRST BURST SIZE is also specified in 512-byte increments. The question is,
does the burst size (FIRST or MAXIMUM) have more to do with the blocksize or
the transport. SAS has a maximum frame payload of 1024 bytes, so a FIRST
BURST SIZE set to a value that is a multiple of 2 (times 512) works nicely,
regardless of the underlying blocksize.
Would parameter rounding be a way to deal with this for target devices that
prefer to align bursts on block boundaries with DIF?
Another issue - a device that supports transferring DIF is also required to
support legacy commands (xxPROTECT = 0) that do not transfer DIF fields. Is
the maximum burst size going to be different for one command versus another,
depending on the setting of xxPROTECT?
I think what this means is the burst size is more tightly coupled to the
requirements of the transport rather than the granularity of blocks within
the device. 512 seemed like a reasonable "minimum chunk" for specifying burst
sizes. But maybe both should be specified in bytes? If it's a big enough
issue, then the solution is proably to define a new bit (probably from the
reserved byte 13) to specify that the burst sizes are specified in bytes
rather than bits (or use the entire byte to specify a different value as the
multiplier for burst size, with a value of zero meaning 512).
Bob
-----Original Message-----
From: owner-t10 at t10.org [mailto:owner-t10 at t10.org] On Behalf Of Knight,
Frederick
Sent: Monday, January 26, 2009 8:47 AM
To: Gerry.Houlder at seagate.com; t10 at t10.org
Cc: Narayan.Ayalasomayajula at emulex.com
Subject: RE: SPC-4 question on disconnect-reconnect mode page parameter
* From the T10 Reflector (t10 at t10.org), posted by:
* "Knight, Frederick" <Frederick.Knight at netapp.com>
*
My opinion is that this information existed pre-DIF, and was not updated when
protection information was added to SBC.  Yes, time makes more sense, but the
values are already specified as 512-byte block based, not time based.
So, I would suggest that the proper interpretation is to read the word "data"
as "user data".  The problem is that "user data" is defined in SBC, not in
SPC, but here is the idea:
The MAXIMUM BURST SIZE field indicates the maximum amount of <user> data that
the target port shall transfer during a single data transfer operation. This
value is expressed in increments of 512 <user data> bytes (i.e., a value of
one means 512 bytes <of user data>, two means 1 024 bytes <of user
data>, etc.). The relationship, if any, between data transfer operations
and interconnect tenancies is defined in the individual SCSI transport
protocol standards. A value of zero specifies there is no limit on the amount
of <user> data transferred per data transfer operation.
The issue of course, is that "user data" is defined in SBC (and relates to
protection information that is defined in SBC), but the above text is from
SPC (where "user data" is not defined, and there is no concept of protection
information).
Another choice might be to add something in SBC that further clarifies the
SPC text, and more specifically states that the value in that field
represents "user data".  Or, in SBC, you could say:
If protection information is enabled, then this value is expressed in
increments...
If protection information is not enabled, then this value is expressed in
increments...
Either way, it sounds like we'll be seeing a proposal at the next meeting to
suggest how to deal with this issue.
		Fred Knight
		NetApp
		SAN Standards Technologist
-----Original Message-----
From: Gerry.Houlder at seagate.com [mailto:Gerry.Houlder at seagate.com]
Sent: Friday, January 23, 2009 2:02 PM
To: t10 at t10.org
Cc: Narayan.Ayalasomayajula at emulex.com
Subject: Re: SPC-4 question on disconnect-reconnect mode page parameter
* From the T10 Reflector (t10 at t10.org), posted by:
* Gerry.Houlder at seagate.com
*
Most people think of the maximum burst size in terms of how long a system is
willing to dedicate bandwidth to a particular task. The time concept is
easier to keep in focus when it is related to bytes transferred, not a
multiple of logical blocks that can vary in size.
	    Bill.Martin at emule
	    x.com
	    Sent by:
To
	    owner-t10 at t10.org	      <t10 at t10.org>
cc
<Narayan.Ayalasomayajula at emulex.com
				      >
	    01/21/2009 04:46
Subject
	    PM			      SPC-4 question on
				      disconnect-reconnect mode page
				      parameter
In looking at the disconnect-reconnect mode page in SPC4r17, the definition
for the MAXIMUM BURST SIZE is:
The MAXIMUM BURST SIZE field indicates the maximum amount of data that the
target port shall transfer during a single data transfer operation. This
value is expressed in increments of
512 bytes (i.e., a value of one means 512 bytes, two means 1 024 bytes,
etc.). The relationship, if any, between data transfer operations and
interconnect tenancies is defined in the individual SCSI transport protocol
standards. A value of zero specifies there is no limit on the amount of data
transferred per data transfer operation.
This works for devices that formatted for data in multiples of 512 bytes per
block; however, this does not map well for devices that formatted for
Protection information and the block size is 520 bytes.  I understand that
the data transfer length can be easily compared to number of 512 byte blocks;
however, if you want to have a max burst size of 32 blocks that are 520 bytes
each then this field does not easily map to the number that you want because
33 would map to 32.49 520 byte blocks.	Was there any thought about tying
this to the block size that a storage device was formatted for?
Thanks,
Bill Martin
Emulex
Office of Technology
Industry Standards
916 772-3658
916 765-6875 (Cell)
bill.martin at emulex.com
*
* For T10 Reflector information, send a message with
* 'info t10' (no quotes) in the message body to majordomo at t10.org
*
* For T10 Reflector information, send a message with
* 'info t10' (no quotes) in the message body to majordomo at t10.org
*
* For T10 Reflector information, send a message with
* 'info t10' (no quotes) in the message body to majordomo at t10.org


From George.Penokie at lsi.com  Mon Jan 26 11:24:38 2009
From: George.Penokie at lsi.com (Penokie, George)
Date: Mon, 26 Jan 2009 11:24:38 -0800
Subject: SPC-4 question on disconnect-reconnect mode page parameter
Message-ID: <mailman.45.1441607348.22516.t10@sandbox.t10.org>

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

A few comments.
First Burst Size and Maximum Burst Size may sound like they should be similar
but they are totally unrelated. The size specified in one never was intended
to, nor does it, have any relation to the size specified in the other.
On the issue about 512 being the size incrementor. That was just a convenient
number to pick at would allow larger sizes that was possible in the limited
field space. Devices that have other logical block sizes (e.g., 520 bytes)
have been around long before there was any DIF defined and they managed to
work just fine with a 512 incrementor.
Bye for now,
George Penokie
LSI Corporation
3033 41st St. NW
Suite 100
Rochester, MN 55901
507-328-9017
george.penokie at lsi.com
________________________________
From: owner-t10 at t10.org [mailto:owner-t10 at t10.org] On Behalf Of Sheffield,
Bob
Sent: Monday, January 26, 2009 12:14 PM
To: Kevin D Butt
Cc: Knight, Frederick; Gerry.Houlder at seagate.com;
Narayan.Ayalasomayajula at emulex.com; owner-t10 at t10.org; t10 at t10.org
Subject: RE: SPC-4 question on disconnect-reconnect mode page parameter
Sorry for the technical errors in my earlier posting.
Each 512-byte burst increment counts bytes of frame payload, whether it's a
DIF-enabled READ/WRITE, a legacy READ/WRITE, or some other command like MODE
SENSE or WRITE BUFFER. DIF (if present) is part of the frame payload (the
transport layer doesn't know if DIF is present or not), and so DIF counts
towards the 512 bytes of the burst increment it falls within. So, for
example, if the device is formatted to 512+DIF (520 total per block), and a
WRITE(10) command specifies WRPROTECT = 001b (transfer DIF), the first burst
increment transferred contains 512 bytes for the first block specified, and
the second burst increment contains the 8-bytes of DIF for the first block,
and the first 504 bytes of the second block, etc...
FIRST BURST SIZE and MAXIMUM BURST SIZE should be specified the same way.
Implementations that support first burst size are no doubt implemented so as
to count bytes of frame payload (which includes DIF) as part of the burst
count. If the standard were modified to force larger (frame payload) bursts
when DIF is present, it would likely break some existing implementations, so
that is not a reasonable path to take.
Bob Sheffield
Engenio Storage Group
MegaRAID Architecture
LSI Corporation

www.lsi.com<<a href="http://www.lsi.com/&gt">http://www.lsi.com/&gt;
________________________________
From: Kevin D Butt [mailto:kdbutt at us.ibm.com]
Sent: Monday, January 26, 2009 10:52 AM
To: Sheffield, Bob
Cc: Knight, Frederick; Gerry.Houlder at seagate.com;
Narayan.Ayalasomayajula at emulex.com; owner-t10 at t10.org; t10 at t10.org
Subject: RE: SPC-4 question on disconnect-reconnect mode page parameter
These fields are indeed related to what is needed in the transport.  Separate
the layers and focus only on the transport please.
This is what you would use to limit your maximum frame size you would allow
in your transport.
Kevin D. Butt
SCSI & Fibre Channel Architect, Tape Firmware
MS 6TYA, 9000 S. Rita Rd., Tucson, AZ 85744
Tel: 520-799-5280
Fax: 520-799-2723 (T/L:321)
Email address: kdbutt at us.ibm.com
http://www-03.ibm.com/servers/storage/
From:	"Sheffield, Bob" <Bob.Sheffield at lsi.com>
To:	"Knight, Frederick" <Frederick.Knight at netapp.com>,
"Gerry.Houlder at seagate.com" <Gerry.Houlder at seagate.com>, "t10 at t10.org"
<t10 at t10.org>
Cc:	"Narayan.Ayalasomayajula at emulex.com"
<Narayan.Ayalasomayajula at emulex.com>
Date:	01/26/2009 10:20 AM
Subject:	RE: SPC-4 question on disconnect-reconnect mode page
parameter
________________________________
* From the T10 Reflector (t10 at t10.org), posted by:
* "Sheffield, Bob" <Bob.Sheffield at lsi.com>
*
It's more complicated than that.
I belive MAXIMUM BURST SIZE and FIRST BURST SIZE should be specified the same
way.
FIRST BURST SIZE is also specified in 512-byte increments. The question is,
does the burst size (FIRST or MAXIMUM) have more to do with the blocksize or
the transport. SAS has a maximum frame payload of 1024 bytes, so a FIRST
BURST SIZE set to a value that is a multiple of 2 (times 512) works nicely,
regardless of the underlying blocksize.
Would parameter rounding be a way to deal with this for target devices that
prefer to align bursts on block boundaries with DIF?
Another issue - a device that supports transferring DIF is also required to
support legacy commands (xxPROTECT = 0) that do not transfer DIF fields. Is
the maximum burst size going to be different for one command versus another,
depending on the setting of xxPROTECT?
I think what this means is the burst size is more tightly coupled to the
requirements of the transport rather than the granularity of blocks within
the device. 512 seemed like a reasonable "minimum chunk" for specifying burst
sizes. But maybe both should be specified in bytes? If it's a big enough
issue, then the solution is proably to define a new bit (probably from the
reserved byte 13) to specify that the burst sizes are specified in bytes
rather than bits (or use the entire byte to specify a different value as the
multiplier for burst size, with a value of zero meaning 512).
Bob
-----Original Message-----
From: owner-t10 at t10.org [mailto:owner-t10 at t10.org] On Behalf Of Knight,
Frederick
Sent: Monday, January 26, 2009 8:47 AM
To: Gerry.Houlder at seagate.com; t10 at t10.org
Cc: Narayan.Ayalasomayajula at emulex.com
Subject: RE: SPC-4 question on disconnect-reconnect mode page parameter
* From the T10 Reflector (t10 at t10.org), posted by:
* "Knight, Frederick" <Frederick.Knight at netapp.com>
*
My opinion is that this information existed pre-DIF, and was not updated when
protection information was added to SBC.  Yes, time makes more sense, but the
values are already specified as 512-byte block based, not time based.
So, I would suggest that the proper interpretation is to read the word "data"
as "user data".  The problem is that "user data" is defined in SBC, not in
SPC, but here is the idea:
The MAXIMUM BURST SIZE field indicates the maximum amount of <user> data that
the target port shall transfer during a single data transfer operation. This
value is expressed in increments of 512 <user data> bytes (i.e., a value of
one means 512 bytes <of user data>, two means 1 024 bytes <of user
data>, etc.). The relationship, if any, between data transfer operations
and interconnect tenancies is defined in the individual SCSI transport
protocol standards. A value of zero specifies there is no limit on the amount
of <user> data transferred per data transfer operation.
The issue of course, is that "user data" is defined in SBC (and relates to
protection information that is defined in SBC), but the above text is from
SPC (where "user data" is not defined, and there is no concept of protection
information).
Another choice might be to add something in SBC that further clarifies the
SPC text, and more specifically states that the value in that field
represents "user data".  Or, in SBC, you could say:
If protection information is enabled, then this value is expressed in
increments...
If protection information is not enabled, then this value is expressed in
increments...
Either way, it sounds like we'll be seeing a proposal at the next meeting to
suggest how to deal with this issue.
		Fred Knight
		NetApp
		SAN Standards Technologist
-----Original Message-----
From: Gerry.Houlder at seagate.com [mailto:Gerry.Houlder at seagate.com]
Sent: Friday, January 23, 2009 2:02 PM
To: t10 at t10.org
Cc: Narayan.Ayalasomayajula at emulex.com
Subject: Re: SPC-4 question on disconnect-reconnect mode page parameter
* From the T10 Reflector (t10 at t10.org), posted by:
* Gerry.Houlder at seagate.com
*
Most people think of the maximum burst size in terms of how long a system is
willing to dedicate bandwidth to a particular task. The time concept is
easier to keep in focus when it is related to bytes transferred, not a
multiple of logical blocks that can vary in size.
	    Bill.Martin at emule
	    x.com
	    Sent by:
To
	    owner-t10 at t10.org	      <t10 at t10.org>
cc
<Narayan.Ayalasomayajula at emulex.com
				      >
	    01/21/2009 04:46
Subject
	    PM			      SPC-4 question on
				      disconnect-reconnect mode page
				      parameter
In looking at the disconnect-reconnect mode page in SPC4r17, the definition
for the MAXIMUM BURST SIZE is:
The MAXIMUM BURST SIZE field indicates the maximum amount of data that the
target port shall transfer during a single data transfer operation. This
value is expressed in increments of
512 bytes (i.e., a value of one means 512 bytes, two means 1 024 bytes,
etc.). The relationship, if any, between data transfer operations and
interconnect tenancies is defined in the individual SCSI transport protocol
standards. A value of zero specifies there is no limit on the amount of data
transferred per data transfer operation.
This works for devices that formatted for data in multiples of 512 bytes per
block; however, this does not map well for devices that formatted for
Protection information and the block size is 520 bytes.  I understand that
the data transfer length can be easily compared to number of 512 byte blocks;
however, if you want to have a max burst size of 32 blocks that are 520 bytes
each then this field does not easily map to the number that you want because
33 would map to 32.49 520 byte blocks.	Was there any thought about tying
this to the block size that a storage device was formatted for?
Thanks,
Bill Martin
Emulex
Office of Technology
Industry Standards
916 772-3658
916 765-6875 (Cell)
bill.martin at emulex.com
*
* For T10 Reflector information, send a message with
* 'info t10' (no quotes) in the message body to majordomo at t10.org
*
* For T10 Reflector information, send a message with
* 'info t10' (no quotes) in the message body to majordomo at t10.org
*
* 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 Jan 26 17:39:18 2009
From: keiji_katata at post.pioneer.co.jp (keiji_katata at post.pioneer.co.jp)
Date: Tue, 27 Jan 2009 10:39:18 +0900
Subject: Reflector cleanup notice
Message-ID: <mailman.46.1441607348.22516.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:
John_Pham at sonic.com
sumit.gupta at sun.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 George.Penokie at lsi.com  Tue Jan 27 11:44:26 2009
From: George.Penokie at lsi.com (Penokie, George)
Date: Tue, 27 Jan 2009 12:44:26 -0700
Subject: Preliminary SPL availble
Message-ID: <mailman.47.1441607348.22516.t10@sandbox.t10.org>

* From the T10 Reflector (t10 at t10.org), posted by:
* "Penokie, George" <George.Penokie at lsi.com>
*
For those of you that are interested I have posted a proposed SPL revision 00
as 09-062. Also note that there is a request to replace some of the acronyms
with text on the first page. If you have any comments or questions on this
let me know.
Your request to upload a file or files to the T10 site has been accepted.
Your PDF file will be posted at:
   http://www.t10.org/cgi-bin/ac.pl?t=d&f=09-062r0.pdf
Bye for now, 
George Penokie
LSI Corporation 
3033 41st St. NW 
Suite 100 
Rochester, MN 55901
507-328-9017 
george.penokie at lsi.com
*
* 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  Wed Jan 28 01:00:00 2009
From: lohmeyer at t10.org (T10 List Manager)
Date: Wed, 28 Jan 2009 02:00:00 -0700
Subject: T10 Reflector Monthly Reminder
Message-ID: <mailman.48.1441607348.22516.t10@sandbox.t10.org>

* From the T10 Reflector (t10 at t10.org), posted by:
* T10 List Manager <lohmeyer at t10.org>
*
This is an automatic monthly posting to the T10 Reflector.  If you
receive this message, it means that you are subscribed to the T10
Reflector email list.
The T10 Reflector is provided by the SCSI Trade Association and
maintained by LSI Corp. This reflector exists to discuss INCITS
T10 Technical Committee issues and to disseminate T10-related
information (minutes, meeting notices, etc.).
---------------------------------------------------------------------------
You do not need to be an INCITS T10 Technical Committee member to
use this reflector, however you must agree to:
 * read the INCITS Patent Policy and the INCITS Antitrust Guidelines
 * acknowledge that the activities of the T10 Technical Committee are
   governed by the INCITS policies and procedures as specified in the
   reference documents RD-1 and RD-2
 * acknowledge that draft documents may change at any time, without notice.
The INCITS Patent Policy, the INCITS Antitrust Guidelines, the RD-1, and
the RD-2 are all available on the www.incits.org web site.
If you do not agree to the above conditions, then you must unsubscribe
to this reflector.
---------------------------------------------------------------------------
T10 Reflector is not intended to carry commercial traffic. People who post
advertisements, job offers, etc. will be removed from the reflector.
Please visit http://www.t10.org/t10r.htm for instructions on subscribing,
unsubscribing, or searching the T10 Reflector archives.
*
* 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  Wed Jan 28 15:34:28 2009
From: lohmeyer at t10.org (John Lohmeyer)
Date: Wed, 28 Jan 2009 16:34:28 -0700
Subject: T10 Reflector clean up
Message-ID: <mailman.49.1441607348.22516.t10@sandbox.t10.org>

* From the T10 Reflector (t10 at t10.org), posted by:
* John Lohmeyer <lohmeyer at t10.org>
*
#
#
#
#
#
#
#
#
#
#
It is time again to clean up the T10 Reflector. The following addresses have
bounced consistently since the last clean up and are being removed:
  rkelley at ciprico.com
  muralidhara.hs at hp.com
  TK.Hui at dalsemi.com
  Doug.Cole at dalsemi.com
  Todd.Mowery at seagate.com
  msargeant at broadbus.com
  Norman.Lavoie at syamsoftware.com
  Samit_Ashdhir at Dell.com
  amits at intelliprop.com
  gg_green at yahoo.com
These people may re-subscribe (hopefully, with a better address) by using the
following URL:
  http://www.t10.org/t10r.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 mfitzpatrick at us.fujitsu.com  Thu Jan 29 10:34:53 2009
From: mfitzpatrick at us.fujitsu.com (Michael Fitzpatrick)
Date: Thu, 29 Jan 2009 10:34:53 -0800
Subject: Updated phone number for making reservation for March T10 meetings
Message-ID: <mailman.50.1441607348.22516.t10@sandbox.t10.org>

* From the T10 Reflector (t10 at t10.org), posted by:
* "Michael Fitzpatrick" <mfitzpatrick at us.fujitsu.com>
*
Eaveryone,
For making reservations for the March T10 meetings in Oklahoma City, the
Embassy Suites Hotel suggest you either call the hotel directly or use the
on-line reservation system.  The direct number to the hotel is
1-405-682-6000 (new phone number for announcement sheet), code FUJ.
If you are making reservations on-line, please make sure you fill in the
code (FUJ) at the bottom of the reservation form.
Any questions, please let me know.
Thanks,
Mike Fitzpatrick
Fujitsu
Cell phone  (405) 820-5809
Email		mfitzpatrick at us.fujitsu.com
This message contains information which may be confidential and privileged.
Unless you are the addressee (or authorized to receive for the addressee),
you may not use, copy or disclose to anyone the message or any information
contained in the message. If you have received the message in error, please
advise the sender by reply [email], and delete the message.
*
* 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  Thu Jan 29 23:36:40 2009
From: Bill.Martin at Emulex.Com (Bill.Martin at Emulex.Com)
Date: Thu, 29 Jan 2009 23:36:40 -0800
Subject: Question on SAT re: translation of STANDBY
Message-ID: <mailman.51.1441607348.22516.t10@sandbox.t10.org>

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

SAT2r6 states in table 45 that if the power condition is 03 - standby then
"If the ATA flush command was sent (step 2) and completes
without error, then the SATL shall send an ATA STANDBY IMMEDIATE command to
the ATA device;"
However, SBCr17 states that if a START STOP UNIT command is processed with
the POWER CONDITION field set to ACTIVE, IDLE, or STANDBY, then:
a) the logical unit shall transition to the specified power condition; and
b) the device server shall disable the idle condition timer if it is active
(see SPC-4) and disable the standby condition timer if it is active (see
SPC-4) until another START STOP UNIT command is processed that returns
control of the power condition to the logical unit, or a logical unit reset
occurs.
This requires disabling the standby condition timer.  This would require
setting the count field to zero in the STANDBY command sent to the ATA
device.
Was there a reason for not setting the count field to zero, or was this an
oversight?  I did not find any comment addressing this in the letter ballot
comments.
Thanks,
Bill Martin
Emulex
Office of Technology
Industry Standards
916 772-3658
916 765-6875 (Cell)
bill.martin at emulex.com


From MOverby at nvidia.com  Fri Jan 30 09:12:50 2009
From: MOverby at nvidia.com (Mark Overby)
Date: Fri, 30 Jan 2009 09:12:50 -0800
Subject: Question on SAT re: translation of STANDBY
Message-ID: <mailman.52.1441607348.22516.t10@sandbox.t10.org>

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

Issuing STANDBY IMMEDIATE forces the timer to be disable until you return to
the active state. (It has an equivalent behavior of the timer going to zero
immediately) (I'm excluding the unload feature of the standby immediate for
simplicity). So I believe it accomplishes what was expected.
Also, when that translation was first created - no timers were supported.
On 1/29/09 11:36 PM, "Bill.Martin at Emulex.Com" <Bill.Martin at Emulex.Com> wrote:
SAT2r6 states in table 45 that if the power condition is 03 - standby then
"If the ATA flush command was sent (step 2) and completes
without error, then the SATL shall send an ATA STANDBY IMMEDIATE command to
the ATA device;"
However, SBCr17 states that if a START STOP UNIT command is processed with
the POWER CONDITION field set to ACTIVE, IDLE, or STANDBY, then:
a) the logical unit shall transition to the specified power condition; and
b) the device server shall disable the idle condition timer if it is active
(see SPC-4) and disable the standby condition timer if it is active (see
SPC-4) until another START STOP UNIT command is processed that returns
control of the power condition to the logical unit, or a logical unit reset
occurs.
This requires disabling the standby condition timer. This would require
setting the count field to zero in the STANDBY command sent to the ATA
device.
Was there a reason for not setting the count field to zero, or was this an
oversight?  I did not find any comment addressing this in the letter ballot
comments.
Thanks,
Bill Martin
Emulex
Office of Technology
Industry Standards
916 772-3658
916 765-6875 (Cell)
bill.martin at emulex.com
-----------------------------------------------------------------------------
------
This email message is for the sole use of the intended recipient(s) and may
contain
confidential information.  Any unauthorized review, use, disclosure or
distribution
is prohibited.	If you are not the intended recipient, please contact the
sender by
reply email and destroy all copies of the original message.
-----------------------------------------------------------------------------
------


From Gerry.Houlder at seagate.com  Fri Jan 30 11:07:22 2009
From: Gerry.Houlder at seagate.com (Gerry.Houlder at seagate.com)
Date: Fri, 30 Jan 2009 13:07:22 -0600
Subject: Question on SAT re: translation of STANDBY
Message-ID: <mailman.53.1441607348.22516.t10@sandbox.t10.org>

* From the T10 Reflector (t10 at t10.org), posted by:
* Gerry.Houlder at seagate.com
*
So lets take this one step further: after the timer is disabled, what
happens when another START STOP command causes the timer to be re-enabled?
The SATL will have to put some non-zero value in for the timer. Will the
SATL remember the previous value that used to be set for that timer so it
can be resent?
	     Mark Overby						   
	     <MOverby at nvidia.c						   
	     om>							To 
	     Sent by:		       "Bill.Martin at Emulex.Com" 	   
	     owner-t10 at t10.org	       <Bill.Martin at emulex.com>,	   
	     No Phone Info	       "t10 at t10.org" <t10 at t10.org>	   
	     Available							cc 
				       "Narayan.Ayalasomayajula at Emulex.Com 
				       "				   
	     01/30/2009 11:12	       <Narayan.Ayalasomayajula at emulex.com 
	     AM 		       >				   
								   Subject 
				       Re: Question on SAT re: translation 
				       of STANDBY			   
Issuing STANDBY IMMEDIATE forces the timer to be disable until you return
to the active state. (It has an equivalent behavior of the timer going to
zero immediately) (I???m excluding the unload feature of the standby
immediate for simplicity). So I believe it accomplishes what was expected.
Also, when that translation was first created ??? no timers were supported.
On 1/29/09 11:36 PM, "Bill.Martin at Emulex.Com" <Bill.Martin at Emulex.Com>
wrote:
      SAT2r6 states in table 45 that if the power condition is 03 ??? standby
      then ???If the ATA flush command was sent (step 2) and completes
      without error, then the SATL shall send an ATA STANDBY IMMEDIATE
      command to the ATA device;???
      However, SBCr17 states that if a START STOP UNIT command is processed
      with the POWER CONDITION field set to ACTIVE, IDLE, or STANDBY, then:
      a) the logical unit shall transition to the specified power
      condition; and
      b) the device server shall disable the idle condition timer if it is
      active (see SPC-4) and disable the standby condition timer if it is
      active (see SPC-4) until another START STOP UNIT command is processed
      that returns control of the power condition to the logical unit, or a
      logical unit reset occurs.
      This requires disabling the standby condition timer. This would
      require setting the count field to zero in the STANDBY command sent
      to the ATA device.
      Was there a reason for not setting the count field to zero, or was
      this an oversight?  I did not find any comment addressing this in the
      letter ballot comments.
      Thanks,
      Bill Martin
      Emulex
      Office of Technology
      Industry Standards
      916 772-3658
      916 765-6875 (Cell)
      bill.martin at emulex.com
This email message is for the sole use of the intended recipient(s) and may
contain confidential information.  Any unauthorized review, use, disclosure
or distribution is prohibited.	If you are not the intended recipient,
please contact the sender by reply email and destroy all copies of the
original message.
*
* For T10 Reflector information, send a message with
* 'info t10' (no quotes) in the message body to majordomo at t10.org


From MOverby at nvidia.com  Fri Jan 30 11:15:50 2009
From: MOverby at nvidia.com (Mark Overby)
Date: Fri, 30 Jan 2009 11:15:50 -0800
Subject: Question on SAT re: translation of STANDBY
Message-ID: <mailman.54.1441607348.22516.t10@sandbox.t10.org>

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

If the SATL supports timers, yes.
On 1/30/09 11:07 AM, "Gerry.Houlder at seagate.com" <Gerry.Houlder at seagate.com>
wrote:
So lets take this one step further: after the timer is disabled, what
happens when another START STOP command causes the timer to be re-enabled?
The SATL will have to put some non-zero value in for the timer. Will the
SATL remember the previous value that used to be set for that timer so it
can be resent?
	     Mark Overby
	     <MOverby at nvidia.c
	     om>							To
	     Sent by:		       "Bill.Martin at Emulex.Com"
	     owner-t10 at t10.org	       <Bill.Martin at emulex.com>,
	     No Phone Info	       "t10 at t10.org" <t10 at t10.org>
	     Available							cc
				       "Narayan.Ayalasomayajula at Emulex.Com
				       "
	     01/30/2009 11:12	       <Narayan.Ayalasomayajula at emulex.com
	     AM 		       >
								   Subject
				       Re: Question on SAT re: translation
				       of STANDBY
Issuing STANDBY IMMEDIATE forces the timer to be disable until you return
to the active state. (It has an equivalent behavior of the timer going to
zero immediately) (I'm excluding the unload feature of the standby
immediate for simplicity). So I believe it accomplishes what was expected.
Also, when that translation was first created - no timers were supported.
On 1/29/09 11:36 PM, "Bill.Martin at Emulex.Com" <Bill.Martin at Emulex.Com>
wrote:
      SAT2r6 states in table 45 that if the power condition is 03 - standby
      then "If the ATA flush command was sent (step 2) and completes
      without error, then the SATL shall send an ATA STANDBY IMMEDIATE
      command to the ATA device;"
      However, SBCr17 states that if a START STOP UNIT command is processed
      with the POWER CONDITION field set to ACTIVE, IDLE, or STANDBY, then:
      a) the logical unit shall transition to the specified power
      condition; and
      b) the device server shall disable the idle condition timer if it is
      active (see SPC-4) and disable the standby condition timer if it is
      active (see SPC-4) until another START STOP UNIT command is processed
      that returns control of the power condition to the logical unit, or a
      logical unit reset occurs.
      This requires disabling the standby condition timer. This would
      require setting the count field to zero in the STANDBY command sent
      to the ATA device.
      Was there a reason for not setting the count field to zero, or was
      this an oversight?  I did not find any comment addressing this in the
      letter ballot comments.
      Thanks,
      Bill Martin
      Emulex
      Office of Technology
      Industry Standards
      916 772-3658
      916 765-6875 (Cell)
      bill.martin at emulex.com
This email message is for the sole use of the intended recipient(s) and may
contain confidential information.  Any unauthorized review, use, disclosure
or distribution is prohibited.	If you are not the intended recipient,
please contact the sender by reply email and destroy all copies of the
original message.


From Bill.Martin at emulex.com  Sat Jan 31 14:06:52 2009
From: Bill.Martin at emulex.com (Bill.Martin at emulex.com)
Date: Sat, 31 Jan 2009 14:06:52 -0800
Subject: Question on SAT re: translation of STANDBY
Message-ID: <mailman.55.1441607348.22516.t10@sandbox.t10.org>

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

Mark:
I have looked in ATA8-ACS, and I cannot find the wording that mandates this. 
There is no count field in the STANDBY IMMEDIATE command, but there is
nothing to indicate that the timer is disabled when the device transitions
back to active.  The SCSI command requires that the timer be disabled until
another START STOP UNIT command is received.
Bill Martin
Emulex
Office of Technology
Industry Standards
916 772-3658
916 765-6875 (Cell)
bill.martin at emulex.com
From: Mark Overby [mailto:MOverby at nvidia.com]
Sent: Friday, January 30, 2009 9:13 AM
To: Martin, Bill; t10 at t10.org
Cc: Ayalasomayajula, Narayan
Subject: Re: Question on SAT re: translation of STANDBY
Issuing STANDBY IMMEDIATE forces the timer to be disable until you return to
the active state. (It has an equivalent behavior of the timer going to zero
immediately) (I'm excluding the unload feature of the standby immediate for
simplicity). So I believe it accomplishes what was expected.
Also, when that translation was first created - no timers were supported.
On 1/29/09 11:36 PM, "Bill.Martin at Emulex.Com" <Bill.Martin at Emulex.Com> wrote:
SAT2r6 states in table 45 that if the power condition is 03 - standby then
"If the ATA flush command was sent (step 2) and completes
without error, then the SATL shall send an ATA STANDBY IMMEDIATE command to
the ATA device;"
However, SBCr17 states that if a START STOP UNIT command is processed with
the POWER CONDITION field set to ACTIVE, IDLE, or STANDBY, then:
a) the logical unit shall transition to the specified power condition; and
b) the device server shall disable the idle condition timer if it is active
(see SPC-4) and disable the standby condition timer if it is active (see
SPC-4) until another START STOP UNIT command is processed that returns
control of the power condition to the logical unit, or a logical unit reset
occurs.
This requires disabling the standby condition timer. This would require
setting the count field to zero in the STANDBY command sent to the ATA
device.
Was there a reason for not setting the count field to zero, or was this an
oversight?  I did not find any comment addressing this in the letter ballot
comments.
Thanks,
Bill Martin
Emulex
Office of Technology
Industry Standards
916 772-3658
916 765-6875 (Cell)
bill.martin at emulex.com
________________________________
This email message is for the sole use of the intended recipient(s) and may
contain confidential information.  Any unauthorized review, use, disclosure
or distribution is prohibited.	If you are not the intended recipient, please
contact the sender by reply email and destroy all copies of the original
message.
________________________________


From lohmeyer at t10.org  Sat Jan 31 23:00:50 2009
From: lohmeyer at t10.org (T10 Document Administrator)
Date: Sun, 1 Feb 2009 00:00:50 -0700
Subject: Recent T10 documents uploaded since 2009/01/25
Message-ID: <mailman.56.1441607348.22516.t10@sandbox.t10.org>

* From the T10 Reflector (t10 at t10.org), posted by:
* T10 Document Administrator <lohmeyer at t10.org>
*
Proposals
---------
Proposed SPL Revison 0
(by: George Penokie)
T10/09-062r0   Uploaded: 2009/01/27   8275761 bytes
http://www.t10.org/cgi-bin/ac.pl?t=d&f=09-062r0.pdf
Minutes: ADC-3 Teleconference Minutes for January 28th 2009
(by: Curtis Ballard)
T10/09-064r0   Uploaded: 2009/01/28   27793 bytes
http://www.t10.org/cgi-bin/ac.pl?t=d&f=09-064r0.pdf
Working Drafts
--------------
SCSI Architecture Model - 5 (SAM-5)
(Editor: George Penokie)
 Rev: 01       Uploaded: 2009/01/27   1120727 bytes
http://www.t10.org/cgi-bin/ac.pl?t=f&f=sam5r01.pdf
(Report generated on 2009/02/01 at 00:00:50)
*
* For T10 Reflector information, send a message with
* 'info t10' (no quotes) in the message body to majordomo at t10.org