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

Holt, Keith keith.holt at engenio.com
Thu May 19 13:03:04 PDT 2005


* From the T10 Reflector (t10 at t10.org), posted by:
* "Holt, Keith" <keith.holt at engenio.com>
*
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



------_=_NextPart_001_01C55CAD.C47E20A8
Content-Type: text/html

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
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


------_=_NextPart_001_01C55CAD.C47E20A8--


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





More information about the T10 mailing list