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

[Ballard, Curtis C (StorageWorks)]

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

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/