Comments on T10 proposal 05-101r1 (part 2)

George Penokie gop at us.ibm.com
Thu May 19 14:03:01 PDT 2005


* From the T10 Reflector (t10 at t10.org), posted by:
* George Penokie <gop at us.ibm.com>
*
This is a multipart message in MIME format.
--=_alternative 0073891886257006_=
Content-Type: text/plain; charset="US-ASCII"


Kieth, 

Your assumption that the FFFFh was only a intended to be a special case
for reads is correct. 

The other side issue is interesting. The case I was thinking about is
one were the application client never touches the application tag field.
That could cause a read of any sector to have the checking always
disabled if the application does not set the application tag to some
value. I think, perhaps, there should be wording added it SBC the states
that an application client that knows about and is using protection
should set the application tag to a value other than FFFFh during
writes. 

Bye for now,
George Penokie

Dept 2C6  114-2 N212
E-Mail:    gop at us.ibm.com
Internal:  553-5208
External: 507-253-5208   FAX: 507-253-2880





"Holt, Keith" <keith.holt at engenio.com> 


05/19/2005 03:03 PM 

To
George Penokie/Rochester/IBM at IBMUS, Gerry.Houlder at seagate.com 

cc
owner-t10 at t10.org, t10 at t10.org 

Subject
RE: Comments on T10 proposal 05-101r1 (part 2)

	





George, 
  
I agree with your statement in part 1 of your response that restoring
the original text is not a good solution.  The WRPROTECT field specifies
in great detail whether the device server shall, shall not, or may check
each of the three fields with no mention of FFFFh in the application
tag.  The current wording obviously takes precedence over intent, but my
recollection of our intent was that an application tag of FFFFh was a
special case only for read commands.  The wording in the protection
information model that made this ambiguous was not present in revision
15 of SBC-2. 
  
That said, even if FFFFh does not disable all write checking, if the ATO
bit is set to 1, an application client that has no use for the
application tag would be ill-advised to set it to FFFFh.  Wouldn't that
result in checking being disabled in the device server for all
protection fields on subsequent reads? 
  
Regards, 
  
Keith 

-- 
Keith Holt 


Engenio Information Technologies, Inc. 
3718 N. Rock Road 
Wichita, KS  67226 
316 636 8665 phone 
keith.holt at engenio.com 





  _____  

From: owner-t10 at t10.org [mailto:owner-t10 at t10.org] On Behalf Of George
Penokie
Sent: Tuesday, May 17, 2005 4:53 PM
To: Gerry.Houlder at seagate.com
Cc: owner-t10 at t10.org; t10 at t10.org
Subject: Re: Comments on T10 proposal 05-101r1 (part 2)


Gerry, 

I addition, if you require the FFFFh value in the application tag to
disable all write checking then you are requiring an application client
to make sure it sets the application tag to some value other than FFFFh,
even if it has no use for the application tag. That would be the case
because the default value for the application tag is FFFFh and if the
application client does nothing to change it then any write checking it
expected would not occur. That's not very user friendly. So you better
have a good reason for putting that requirement on applications. 

Bye for now,
George Penokie

Dept 2C6  114-2 N212
E-Mail:    gop at us.ibm.com
Internal:  553-5208
External: 507-253-5208   FAX: 507-253-2880




Gerry.Houlder at seagate.com 
Sent by: owner-t10 at t10.org 


05/17/2005 03:19 PM 



To
t10 at t10.org 

cc

Subject
Comments on T10 proposal 05-101r1


	






* From the T10 Reflector (t10 at t10.org), posted by:
* Gerry.Houlder at seagate.com
*
This proposal adds wording that states "A LOGICAL BLOCK APPLICATION TAG
field set to FFFFh disables checking of all protection information for
the
logical block when reading from the medium."

I don't believe this restriction is a good idea. This disabling of all
checking should also occur for writes as well.

Consider design of target hardware to implement this function. The
hardware
needs to be designed so that an Application Tag value of FFFFh overrides
any checking that would otherwise be permitted by the RDPROTECT field in
the CDB. Now imagine that the same hardware will be used for checking
data
|from a WRITE command. Is it reasonable that the target should redesign
the
same hardware so that  the WRPROTECT field overrides the Application Tag
value of FFFFh? We don't think so.

If there is another reason (other than just making the wording more
specific) I'd like to hear it. Otherwise I would like to see this change
withdrawn or I make a new proposal that changes the wording to "either
writing or reading".

*
* For T10 Reflector information, send a message with
* 'info t10' (no quotes) in the message body to majordomo at t10.org



--=_alternative 0073891886257006_=
Content-Type: text/html; charset="US-ASCII"


<br><font size=2 face="sans-serif">Kieth,</font>
<br>
<br><font size=2 face="sans-serif">Your assumption that the FFFFh was only
a intended to be a special case for reads is correct. </font>
<br>
<br><font size=2 face="sans-serif">The other side issue is interesting.
The case I was thinking about is one were the application client never
touches the application tag field. That could cause a read of any sector
to have the checking always disabled if the application does not set the
application tag to some value. I think, perhaps, there should be wording
added it SBC the states that an application client that knows about and
is using protection should set the application tag to a value other than
FFFFh during writes.</font>
<br><font size=2 face="sans-serif"><br>
Bye for now,<br>
George Penokie<br>
<br>
Dept 2C6 &nbsp;114-2 N212<br>
E-Mail: &nbsp; &nbsp;gop at us.ibm.com<br>
Internal: &nbsp;553-5208<br>
External: 507-253-5208 &nbsp; FAX: 507-253-2880<br>
<br>
</font>
<br>
<br>
<br>
<table width=100%>
<tr valign=top>
<td width=40%><font size=1 face="sans-serif"><b>"Holt, Keith"
<keith.holt at engenio.com&gt;</b> </font>
<p><font size=1 face="sans-serif">05/19/2005 03:03 PM</font>
<td width=59%>
<table width=100%>
<tr>
<td>
<div align=right><font size=1 face="sans-serif">To</font></div>
<td valign=top><font size=1 face="sans-serif">George Penokie/Rochester/IBM at IBMUS,
Gerry.Houlder at seagate.com</font>
<tr>
<td>
<div align=right><font size=1 face="sans-serif">cc</font></div>
<td valign=top><font size=1 face="sans-serif">owner-t10 at t10.org, t10 at t10.org</font>
<tr>
<td>
<div align=right><font size=1 face="sans-serif">Subject</font></div>
<td valign=top><font size=1 face="sans-serif">RE: Comments on T10 proposal
05-101r1 (part 2)</font></table>
<br>
<table>
<tr valign=top>
<td>
<td></table>
<br></table>
<br>
<br>
<br><font size=2 color=blue face="Arial">George,</font>
<br><font size=3>&nbsp;</font>
<br><font size=2 color=blue face="Arial">I agree with your statement in
part 1 of your response that restoring the original text is not a good
solution. &nbsp;The WRPROTECT field specifies in great detail whether the
device server shall, shall not, or may check each of the three fields with
no mention of FFFFh in the application tag. &nbsp;The current wording obviously
takes precedence over intent, but my recollection of our intent was that
an application tag of FFFFh was a special case only for read commands.
&nbsp;The wording in the protection information model that made this ambiguous
was not present in revision 15 of SBC-2.</font>
<br><font size=3>&nbsp;</font>
<br><font size=2 color=blue face="Arial">That said, even if FFFFh does
not disable all write checking, if the ATO bit is set to 1, an application
client that has no use for the application tag would be ill-advised to
set it to FFFFh. &nbsp;Wouldn't that result in checking being disabled
in the device server for all protection fields on subsequent reads?</font>
<br><font size=3>&nbsp;</font>
<br><font size=2 color=blue face="Arial">Regards,</font>
<br><font size=3>&nbsp;</font>
<br><font size=2 color=blue face="Arial">Keith</font>
<p><font size=2 color=blue face="Arial">-- <br>
Keith Holt</font>
<p><font size=2 color=blue face="Arial">Engenio Information Technologies,
Inc.</font><font size=3 color=blue> </font><font size=2 color=blue face="Arial"><br>
3718 N. Rock Road</font><font size=3 color=blue> </font><font size=2 color=blue face="Arial"><br>
Wichita, KS &nbsp;67226</font><font size=3 color=blue> </font><font size=2 color=blue face="Arial"><br>
316 636 8665 phone</font><font size=3 color=blue> </font><font size=2 color=blue face="Arial"><br>
keith.holt at engenio.com</font><font size=3 color=blue> </font>
<p>
<br>
<hr><font size=2 face="Tahoma"><b>From:</b> owner-t10 at t10.org [mailto:owner-t10 at t10.org]
<b>On Behalf Of </b>George Penokie<b><br>
Sent:</b> Tuesday, May 17, 2005 4:53 PM<b><br>
To:</b> Gerry.Houlder at seagate.com<b><br>
Cc:</b> owner-t10 at t10.org; t10 at t10.org<b><br>
Subject:</b> Re: Comments on T10 proposal 05-101r1 (part 2)</font><font size=3><br>
</font>
<br><font size=2 face="sans-serif"><br>
Gerry,</font><font size=3> <br>
</font><font size=2 face="sans-serif"><br>
I addition, if you require the FFFFh value in the application tag to disable
all write checking then you are requiring an application client to make
sure it sets the application tag to some value other than FFFFh, even if
it has no use for the application tag. That would be the case because the
default value for the application tag is FFFFh and if the application client
does nothing to change it then any write checking it expected would not
occur. That's not very user friendly. So you better have a good reason
for putting that requirement on applications.</font><font size=3> </font><font size=2 face="sans-serif"><br>
<br>
Bye for now,<br>
George Penokie<br>
<br>
Dept 2C6 &nbsp;114-2 N212<br>
E-Mail: &nbsp; &nbsp;gop at us.ibm.com<br>
Internal: &nbsp;553-5208<br>
External: 507-253-5208 &nbsp; FAX: 507-253-2880<br>
</font><font size=3><br>
<br>
<br>
</font>
<table width=100%>
<tr valign=top>
<td width=42%><font size=1 face="sans-serif"><b>Gerry.Houlder at seagate.com</b>
<br>
Sent by: owner-t10 at t10.org</font><font size=3> </font>
<p><font size=1 face="sans-serif">05/17/2005 03:19 PM</font><font size=3>
</font>
<td width=57%>
<br>
<table width=100%>
<tr>
<td width=17%>
<div align=right><font size=1 face="sans-serif">To</font></div>
<td width=82% valign=top><font size=1 face="sans-serif">t10 at t10.org</font><font size=3>
</font>
<tr>
<td>
<div align=right><font size=1 face="sans-serif">cc</font></div>
<td valign=top>
<tr>
<td>
<div align=right><font size=1 face="sans-serif">Subject</font></div>
<td valign=top><font size=1 face="sans-serif">Comments on T10 proposal
05-101r1</font></table>
<br>
<br>
<table width=100%>
<tr valign=top>
<td width=49%>
<td width=50%></table>
<br></table>
<br><font size=3><br>
<br>
</font><font size=2><tt><br>
* From the T10 Reflector (t10 at t10.org), posted by:<br>
* Gerry.Houlder at seagate.com<br>
*<br>
This proposal adds wording that states "A LOGICAL BLOCK APPLICATION
TAG<br>
field set to FFFFh disables checking of all protection information for
the<br>
logical block when reading from the medium."<br>
<br>
I don't believe this restriction is a good idea. This disabling of all<br>
checking should also occur for writes as well.<br>
<br>
Consider design of target hardware to implement this function. The hardware<br>
needs to be designed so that an Application Tag value of FFFFh overrides<br>
any checking that would otherwise be permitted by the RDPROTECT field in<br>
the CDB. Now imagine that the same hardware will be used for checking data<br>
|from a WRITE command. Is it reasonable that the target should redesign
the<br>
same hardware so that &nbsp;the WRPROTECT field overrides the Application
Tag<br>
value of FFFFh? We don't think so.<br>
<br>
If there is another reason (other than just making the wording more<br>
specific) I'd like to hear it. Otherwise I would like to see this change<br>
withdrawn or I make a new proposal that changes the wording to "either<br>
writing or reading".<br>
<br>
*<br>
* For T10 Reflector information, send a message with<br>
* 'info t10' (no quotes) in the message body to majordomo at t10.org</tt></font><font size=3><br>
</font>
<br>
--=_alternative 0073891886257006_=--





More information about the T10 mailing list