[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: growisofs DVD-R[W] DAO can fail with piped input

scdbackup@gmx.net wrote:
Hi Andy,

while learning how dvd+rw-tools is doing its work,
i meanwhile came to DVD-RW Disk-At-Once where i
discovered a processing path in the code which
avoids the track reservation. Another related path
seems to reserve a size that might be too small.

I tested those use cases with growisofs 7.0. It looks that
at least my drives do not appreciate what growisofs
is doing. (Are there drives known which would do ?)

The code which made me think is in growisofs_mmc.cpp :
            if (is_dao && leadout)

Before each burn the DVD-RW was treated with
  $ dvd+rw-format -blank /dev/sr0

Submitting a logical track of unspecified length
seems indeed to circumvent 53h RESERVE TRACK and
next it fails:

  $ dd if=/dev/zero bs=2048 count=500000 | \
    growisofs -use-the-force-luke=dao -Z /dev/sr0=/dev/fd/0
  /dev/sr0: engaging DVD-RW DAO upon user request...

Here function  minus_r_reserve_track()  with a disk file
as source would state something like
  /dev/sr0: reserving 500000 blocks
In this case it doesn't, but rather states as next lines:

  /dev/sr0: "Current Write Speed" is 4.1x1352KBps.
  :-! "COMMAND SEQUENCE ERROR"@LBA=0h. Is media being read?
  :-! the LUN appears to be stuck at 0h, retrying in 5 secs...

I waited about a minute but no progress was visible
with the subsequent retries.

"Command sequence error" looks much like 53h RESERVE TRACK
is mandatory with DAO DVD-RW. I believe the first 2Ah WRITE
came when the drive was still awaiting some setup.

Looks like this would happen with any piped input which is
not in ISO-9660 format (E.g. afio, star) and has no explicit
size given via -use-the-force-luke.

Next there is a problem if a ISO-9660 header does not predict
the full length of the data stream.

The specs stay undecided. mmc5r03c.pdf :
"Based upon the currently mounted media, it is possible
 for the Host to request a Reservation Size that is too small."

By chance i got a real use case for such ISO images:

My backup project appends checksum data to its ISO-9660 images.
With Incremental Streaming this only has the funny effect of
getting reported more than 100% "done" with the pacifier messages.
But with DAO :

  $ dd if=/dvdbuffer/fertig.iso | \
    growisofs -use-the-force-luke=dao -Z /dev/sr0=/dev/fd/0
  /dev/sr0: engaging DVD-RW DAO upon user request...
  /dev/sr0: reserving 64046 block, warning for short DAO recording
  /dev/sr0: "Current Write Speed" is 4.1x1352KBps.
  :-? the LUN appears to be stuck writing LBA=fa30h, keep retrying in 23ms

Again, no progress with the retries. I pressed CTRL+C
and after some due waiting time, the process ended.

The file  fertig.iso  is 32313 bytes larger than the
reserved track size of 64046 * 2048.
When giving the disk file as source, everthing is ok:
  $ growisofs -use-the-force-luke=dao -Z /dev/sr0=/dvdbuffer/fertig.iso
  /dev/sr0: reserving 64061 block, warning for short DAO recording

Since DAO is avoidable only if i do
it is not purely deliberate user risk but could also bite me
if i inadvertedly use such media.

(I did not test yet the situation where a track source is smaller
than announced by the ISO-9660 header.)

For cdrskin i decided to:
- disallow undefined track size with DVD-R[W] DAO
  and demand a recognizable file size or an explicit
  track size.
- truncate the data stream to the reserved size
  and eventually indicate failure by its exit value.
- pad up tracks where the data source does not deliver
  the announced size.
So DVD-R[W] DAO will behave like single track CD SAO.

Just for reference, Joerg and I had a discussion of this, related to doing remote backups where the ISO image is generated on one machine and piped to cdrecord on another. It appears to have the same limitations, you need to create an image somewhere to do the burn, and in addition to the disk required the time per media is transfer+burn instead of just burn (since the transfer is always faster than the burn, at least for the moment).

bill davidsen <davidsen@tmr.com>
 CTO TMR Associates, Inc
 Doing interesting things with small computers since 1979

Reply to: