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)
minus_r_reserve_track(cmd,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 6.31.2.4 :
"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
dvd+rw-format-blank=full
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.