Chair action item #1

keiji_katata at post.pioneer.co.jp keiji_katata at post.pioneer.co.jp
Thu Sep 28 19:40:31 PDT 2006


* From the T10 Reflector (t10 at t10.org), posted by:
* keiji_katata at post.pioneer.co.jp
*
Hello all,
I have an action item that issues a letter to survey the opinion of all
interested parties. The typical parties may be Software venders and PC
venders.
Software venders may be affected this change of drive behavior. PC venders
may
also be affected because they use many test software or test system of the
MMC
devices. If such test system has problem by this change, it could be a
problem
of the muss production.
I have two questions. I would like to ask the first question in this email.
First Survey Item:
2/4/7 or 2/4/8 error during READ with Restricted Overwrite and Rigid
Restricted
Overwrite
Here is the copy from the September Mt. Fuji minutes.
------ Copy from minutes ------
7.3.6 2/4/7 or 2/4/8 error during READ with Restricted Overwrite and Rigid
Restricted Overwrite
Is it permitted for a READ(10/12) command to post 2/4/7 or 2/4/8 when a write
is
in progress from the drive's buffer?
MMC and Fuji say:
"When Restricted Overwrite method is currently performed (Restricted
Overwrite
Feature (0026h) or Rigid Restricted Overwrite Feature (002Ch)), READ (10)
command or READ (12) command shall be performed normally after data in buffer
is
written on the disc."
So, a SYNC CACHE is forced.  The open question is: "May the drive post 2/4/7
or
2/4/8?"
Microsoft, Ulead, Sonic and Panasonic believe that it is OK.  Pioneer states
that the drive should wait until the data can be read, but with a time limit
of
5-8 seconds.  If the time limit is exceeded, then either 2/4/7 or 2/4/8 may
be
posted.
Others wish to study further.  This topic is deferred until the October
meeting.
------------ End ------------
First Question:
I would like to hear your answer to this question that "Can you accept 2/4/8
error termination of Read command that causes data write operation that may
take
more than 8 sec?"
I would like to explain the histories about 2/4/8 error of Buffer overflows
control during data writing.
History:
Here is the copy from "17.48 WRITE (10) command" of the Fuji6r100.pdf that
state
about 2/4/8 error.
-------Copy from Fuji5 -------
While writing is occurring, if WRITE (10) command or WRITE (12) command
cannot
be terminated immediately due to insufficient buffer capacity, the logical
unit
may terminate the WRITE command with CHECK CONDITION status, 2/04/08 LOGICAL
UNIT NOT READY, LONG WRITE IN PROGRESS and the host shall issue the same
WRITE
command again. After logical unit becomes ready due to sufficient buffer
capacity for the WRITE command, the WRITE command shall be performed
normally.
When Restricted Overwrite method is currently performed (Restricted Overwrite
Feature (0026h) or Rigid Restricted Overwrite Feature (002Ch)), READ (10)
command or READ (12) command shall be performed normally after data in buffer
is
written on the disc.
------------ End ------------
This statement has been revised at Fuji5 period to allow Buffer overflow
control
protocol for CD-R/RW, DVD-R/RW data writing. The original statement was in
10.47
WRITE (10) Command of Fuji3v50.pdf as follows.
------ Copy from Fuji3 ------
All other commands shall execute normally, but may force a FLUSH CACHE before
executing. The process of writing from the Logical Unit's cache to the medium
shall not cause a NOT READY condition for any command. CHECK CONDITION
Status,
2/04/08 LOGICAL UNIT NOT READY, LONG WRITE IN PROGRESS may exist when the
Logical Unit is padding a reserved track or writing Lead-in and Lead-out.
------------ End ------------
This allowed 2/4/8 error only for the case of Track padding at Track at Once
and
Lead-in/Lead-out padding at DAO/SAO those are performed automatically by
drive
after a Write command. Here was the proposal to change this Fuji3 statement
to
the Fuji5 statement at <
ftp.avc-pioneer.com//Mtfuji_5/Proposal/Aug01/proposal.zip&gt; and
<ftp.avc-pioneer.com//Mtfuji_5/Proposal/Sep01/pioneer/write.pdf&gt;.
>From these documents, it is clear that 2/4/8 error of Buffer overflow
control
protocol is allowed only for Write 10/12 command of the CD-R/RW and DVD-R/RW.
Read 10/12 command just after Write 10/12 command shall be performed normally
except fatal error occurrence.
Background of the discussion:
I would like to explain the background of the section 7.3.6 discussion of the
last minutes.
A UDF file system driver that supports writing/reading on Random rewritable
optical disc (e.g. DVD-RAM) and Restricted over-writable optical disc (e.g.
DVD-RW) is ready to be released with an OS. The driver has 1MB write buffer
and
uses Read 10 command after Write 10 command to verify the written data on the
Restricted over-writable optical disc. The driver writes 1MB (32 ECC blocks)
data at a write then reads the 1MB sectors. Usually optical drive of
Restricted
over-writable has more than 1MB data buffer. So 1MB data of a write is stored
in
buffer and then is written at the first Read 10 command after the Write 10
command. Normally the 1MB data write may take less than 1 sec. But there is a
possibility that it takes more than 10 sec when new write occurs on other
layers, other temperature and other regions. Layer change, temperature change
and region change (inside <> outside) may cause new OPC in drive. If the new
OPC
is failed the second OPC will be performed. In such worst case the Read 10
command may exceed 10 sec. 2/4/8 error of Buffer overflow control does not
work
for this Read10 command. It is because that there is no buffer overflow in
the
drive and Read 10 command shall be performed normally with implicit
Sync-cache.
Currently OS driver such has time-out timer will issue time-out reset to I/O.
But if the drive connection has a bridge (USB bridge, SATA bridge, LAN bridge
and etc.) this OS time-out reset does not work correctly. Sometimes the
result
is unknown. And also this time-out makes unnecessary defective sectors of the
disc.
As the result, the UDF driver may need to be modified or the MMC drive shall
not
cause any time-out of OS.
Could you send your answer to above question to reflector?
Any question or comment is appreciated.
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



More information about the T10 mailing list