Objections to 10-043r0 changing the intent of the wtc bit in WRITE ATTRIBUTE command

[Kevin D Butt]

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

Curtis,
Thanks for the response.  I understand your concern but believe that this 
is clear in the current text. In my mind the current text, 
<<The write-through cache (WTC) bit set to one specifies the attributes in 
the parameter list shall be synchronized with the medium auxiliary memory 
during the processing of the WRITE ATTRIBUTE command and GOOD status shall 
not be returned until the attributes have been synchronized with the 
medium auxiliary memory.>> 
states that the command shall be held and the attribute synched to MAM 
before GOOD status can be returned. I can see from a device server 
perspective how, depending on your queuing model, other commands may be 
accepted and processed.  However, from an application perspective, if the 
application needs to block its activities until this synch to MAM is 
complete, it can do so not issuing other commands until this WRITE 
ATTRIBUTE command completes.  So it does provide the functionality needed 
by an application to block until the data has been synched to MAM.
The assumptions on how fast WRITE ATTRIBUTE returns will undoubtedly vary 
|from vendor to vendor.	The only amount of time that an application has 
the right to expect is the timeout value returned in the REPORT SUPPORTED 
OPERATION CODE command.  Any other time is an assumption that is 
inherently inaccurate.	The wtc bit is a new function that clarifies 
behavior.  Prior to the wtc bit a device server may have operated this way 
on all WRITE ATTRIBUTE commands.  An application has to handle that today. 
 If you are concerned about the increase in time, then go into the REPORT 
SUPPORTED OPERATION CODE command and add a command specific timeout for 
the WRITE ATTRIBUTE command when the wtc bit is set to one.
Thanks,
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:
"Ballard, Curtis C (StorageWorks)" <curtis.ballard at hp.com>
To:
Kevin D Butt/Tucson/IBM at IBMUS
Cc:
"t10 at t10.org" <t10 at t10.org>
Date:
03/05/2010 04:20 PM
Subject:
RE: Objections to 10-043r0 changing the intent of the wtc bit in WRITE 
ATTRIBUTE command
Thanks for the thoughts Kevin.	The way WTC is documented currently it is 
not clear that it is intended to be blocking.  I'm not in favor of having 
a blocking WRITE ATTRIBUTE as that is very different from the existing 
WRITE ATTRIBUTE behavior.  All of the use I am aware of for WA has very 
short timeouts and expects a rapid response.  I would like WTC to behave 
the same way.  If the device server isn't able to process the write at 
this time respond quickly with a response that informs the application 
that it needs to try again later. 
The intent of the statement I proposed was to answer your question in your 
last paragraph ? why did the application get this response and what should 
it's response be.  It got the response because the WTC bit is supported 
but it isn't possible to write to MAM right now and what to do is try 
again when the drive is idle.  In practice the application sending the WA 
command should be the same application using the drive and the application 
will know when the drive is idle.
However WTC is supposed to behave I would like it to be very clear.  If it 
is going to respond quickly then we can work with the text I have proposed 
to make it clear what that means and what an application should do.  If 
WTC is supposed to cause WA to block and a long timeout may be required 
then we need to make that clear.
Curtis Ballard
Hewlett Packard
StorageWorks Platforms Tape
Fort Collins, CO
(970) 898-3013
From: Kevin D Butt [mailto:kdbutt at us.ibm.com] 
Sent: Friday, March 05, 2010 3:40 PM
To: Ballard, Curtis C (StorageWorks)
Cc: t10 at t10.org
Subject: Objections to 10-043r0 changing the intent of the wtc bit in 
WRITE ATTRIBUTE command
Curtis, 
Regarding your proposal 10-043r0 "SPC-4: Correct usage of term volume in 
MAM attributes" I have objections with the proposed modification of the 
wtc bit. 
The wtc (write-through cache) bit which was recently included in SPC-4 
(see 09-355r2) is intended to provide a blocking synchronization to MAM 
much like a WRITE FILEMARK is supposed to provide a blocking 
synchronization of buffered data to medium.  The application is blocked 
until GOOD status is returned and then the application can be assured that 
the data is out of the buffer and onto the medium.  That is the same 
intent as the WTC bit with data going to the MAM. 
It would not make sense for a device server to return ILLEGAL REQUEST, 
OPERATION IN PROGRESS to a WRITE FILEMARK command even if the drive was 
doing some extensive error recovery procedure like a head brush that takes 
a long time.  The WRITE FILEMARK command is held in the queue and waits 
until it can be serviced or until the upper layer timeout in the 
application fires and the command is aborted.  In the same token, it does 
not make sense for a WRITE ATTRIBUTE command with the WTC bit set to one 
to return this error just because a device server is busy with something 
else. The WRITE ATTRIBUTE command should be held in the queue until it can 
be serviced and return GOOD status. 
Additionally, should an application receive a response of  ILLEGAL 
REQUEST, OPERATION IN PROGRESS to the WRITE ATTRIBUTE command what would 
be its actions?  It doesn't know why this is returned.	It doesn't know if 
it should reissue the command and if so how long to wait.  In practice 
applications would fail the entire job, call the volume bad, and move to 
use a different volume.  This is not desirable. 
Thanks, 
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/