[Pkg-opt-media-team] Bug#709971: dvd+rw-tools: growisofs more then 1 Bluray, since Debian 7 speed collapses

[Thomas Schmitt]

Hi,

meanwhile i got the SCSI logs from Winfried Muench.

The read log shows long hangs

  READ(10)
  28 00 00 02 74 80 00 00 10 00
     844 ms
  xorriso : UPDATE : 160912 of 320001 blocks read in 36 s , 0.6xB
  ...
  28 00 00 03 07 e0 00 00 10 00
     856 ms
  xorriso : UPDATE : 198640 of 320001 blocks read in 43 s , 1.1xB
  ...
  28 00 00 03 b5 e0 00 00 10 00
     848 ms
  xorriso : UPDATE : 243184 of 320001 blocks read in 53 s , 0.9xB

They often coincide with the pacifier messages of xorriso which
come every five five seconds (or longer, if reading via ioctl(SG_IO)
stalls).

This coincidence gives me the suspicion that the long lasting
READ commands need much more time than the about 0.8 seconds
which are reported by the kernel's time measurement with
ioctl(SG_IO):
  struct sg_io_hdr_t.duration

(I will have to improve the SCSI log by own time measurements
 in userspace which hopefully give a granularity finer than
 than 4 milliseconds.)


The write log shows shorter stalls.
They appear to be grouped as pairs with 6 to 8 intermediate
fast command executions inbetween. Between pairs there are
longer periods of fast execution:

  WRITE(10)
  2a 00 00 03 64 60 00 00 10 00
     108 ms
  ... 7 fast ones ...
  2a 00 00 03 64 d0 00 00 10 00
      44 ms
  ---------------------------------
  2a 00 00 03 71 40 00 00 10 00
     124 ms
  ...  7 fast ones ...
  2a 00 00 03 71 b0 00 00 10 00
      40 ms
  ---------------------------------
  2a 00 00 03 7e 80 00 00 10 00
     112 ms
  ... 8 fast ones ...
  2a 00 00 03 7f 10 00 00 10 00
      36 ms
  ---------------------------------
  2a 00 00 03 8b 20 00 00 10 00
     108 ms
  ... 6 fast ones ...
  2a 00 00 03 8b 90 00 00 10 00
      48 ms

The bytes 3 to 6 of each WRITE command tell the block address
(printed as hex here, little-endian, block size 2048).

Each READ and WRITE command transferred 32 KiB.


-----------------------------------------------------------------
Some non-kernel proposals for a workaround:

One could try to increase the transfer size to 64 KiB.
This reduces the number of commands by a factor of 2 and
might also please driver or burner drive if they put emphasis
on the natural ECC block size of BD media.

Writing:

  xorriso -scsi_log on \
          -as cdrecord -v dev=/dev/srX \
                       dvd_obs=64k \
                       filename.iso \
  > /tmp/xorriso_write_log 2>&1


Reading:

  time xorriso -scsi_log on \
               -outdev /dev/srX \
               -check_media use=outdev min_lba=0 max_lba=320000 \
                            chunk_size=64s -- \
   > /tmp/xorriso_read_log 2>&1


If you can trust the quality of drives and media, then you may
disable Defect Management during writing:

  xorriso -scsi_log on \
          -as cdrecord -v dev=/dev/srX \
                       stream_recording=on \
                       filename.iso \
  > /tmp/xorriso_write_log 2>&1

This should bring the effective write speed much nearer to the
nominal speed of drive and medium. libburn will use WRITE(12)
rather than WRITE(10).
(stream_recording=on on BD media implies dvd_obs=64k but you
 may well give that option explicitely, too.)

If you record checksums of the image files, then you could
use them to verify success with (simultaneously fast) dd
reading.
Even without checksum, a properly readable data stream of
the image's size will give you good certainty that the burn
went well. (If you get I/O error from dd, then it is bad. :))

The practical benefit of Defect Management is limited anyway.
It usually fails earlier than write runs without this feature.
A few bad spots can be worked around, but the usual problematic
medium will just fail more spectacular then.

-----------------------------------------------------------------

Have a nice day :)

Thomas