Re: resuming writing an unclosed DVD+R track

[Ivan Shmakov]

>>>>> Thomas Schmitt wrote:
>>>>> Ivan Shmakov wrote:

 >>   484114432/4700372992 (10.3%) @5.4x, remaining 11:01 RBU 100.0% UBU  98.4%
 >> :-[ WRITE@LBA=39b60h failed with SK=4h/LOGICAL UNIT COMMUNICATION TIMEOUT]:
 >> Input/output error

 > SK=4 means “Drive error”.  The ASC/ASQ combination is probably
 > 08/01 and the message probably stems from the drive’s firmware.
 > (Of course the kernel is free to insert its own Sense Data into
 > the communication between program and drive.)

 > Obviously some entity in the chain lost patience with its
 > communications partner.

        Given that the issue only affects one specific box, I’m
        inclined to chalk it up to a faulty SATA channel.  For instance,
        installing a new drive there didn’t get rid of the problem,
        but moving the original one to another box did.

 > Normally I would advise to repeat the burn with a fresh medium.

        I’ve had several failures like that by that point, and it
        started to get costly to just use fresh blanks, which prompted
        me to investigate the alternatives.

 >>  State of Last Session: incomplete
 >> READ TRACK INFORMATION[#1]:
 >>  Track State:           invisible
 >>  Track Start Address:   0*2KB
 >>  Next Writable Address: 236400*2KB

 > According to MMC specs, DVD+R can have multiple tracks open.  It’s
 > not so clear from the text whether this persists over ejecting and
 > loading the medium.

        Well, at the least I’ve had no issues with resuming a burn in
        such a way after taking the disk out and putting it back.

 > Whatever, this does not fit well into the media model of libburn,
 > which stems from the properties of CD-R media.

        That’s somewhat unfortunate.  I haven’t exactly planned to
        move off growisofs(1), but having alternatives /does/ help,
        especially when something out of ordinary happens.

 > So the only offer which xorriso could make is -close_damaged, which
 > would possibly close the track somewhere after block 236400.
 > Depending on the mood of the drive the DVD+R might stay appendable
 > and you could add more data as second session.

        ACK, thanks.

[…]

 >> growisofs -dvd-compat -speed=6 -overburn
 >> -use-the-force-luke=seek=2288256 -Z /dev/sr0=/tmp/pieces.Vm3nMUcT

 > I don’t think that -use-the-force-luke=seek= is necessary with this
 > run, which goes to track/session 2.

        It doesn’t seem to be properly documented anywhere, but yes,
        it’s possible to use -C DUMMY,NWA -M DEVICE=IMAGE to record
        additional sessions from pre-mastered image files.  (I think
        when it comes to pre-mastered imaged, only the -Z DEVICE=IMAGE
        usage is actually mentioned in the documentation.)

        Nevertheless, it did fail in this specific case:

+ /usr/bin/time -- growisofs -dvd-compat -speed=6 -C 16,2288256 -M 
/dev/sr0=/tmp/pieces.Vm3nMUcT
:-( /dev/sr0 doesn't look like isofs...
Command exited with non-zero status 252
0.00user 0.00system 0:02.33elapsed 0%CPU (0avgtext+0avgdata 2988maxresident)k
2408inputs+0outputs (9major+137minor)pagefaults 0swaps

        So I’ve resorted to -Z with seek=.

 >> :-[ CLOSE TRACK failed with SK=5h/INVALID FIELD IN CDB]: Input/output error

 > growisofs seems slightly disoriented here. :-)

        I guess so.

 > But the drive just rejected the unwanted SCSI command and took no
 > offense.

        I wasn’t as lucky with another disk, though.  What I’ve had is
        a similarly incompletely written DVD+R:

 Track Size:            248448*2KB
 ROM Compatibility LBA: 270336
READ TRACK INFORMATION[#2]:
 Track State:           invisible
 Track Start Address:   250496*2KB
 Next Writable Address: 308800*2KB
 Free Blocks:           1986304*2KB
 Track Size:            2044608*2KB
 ROM Compatibility LBA: 270336
FABRICATED TOC:
 Track#1  :             17@0
 Track#AA :             17@248448
 Multi-session Info:    #1@0
READ CAPACITY:          248448*2048=508821504

        The growisofs(1) run there (after a few weeks; same drive, but
        physically attached to another box, accessed via iSCSI) looks
        almost successful:

$ /usr/bin/time -- growisofs -speed=6 \
      -use-the-force-luke=seek=308800,notray -Z /dev/sr1=/dev/loopXX 
WARNING: /dev/sr1 already carries isofs!
About to execute 'builtin_dd if=/dev/loopXX of=/dev/sr1 obs=32k seek=19300'
/dev/sr1: "Current Write Speed" is 6.1x1352KBps.
  643727360/0 (-1.8%) @2.4x, remaining -5:-41 RBU 100.0% UBU -12.5%
  658997248/0 (-4.2%) @3.3x, remaining -3:-43 RBU 100.0% UBU   3.1%
  673906688/0 (-6.6%) @3.2x, remaining -3:-31 RBU 100.0% UBU  14.8%
  689700864/0 (-9.1%) @3.4x, remaining -3:-12 RBU 100.0% UBU  13.3%
…
 1366097920/0 (-116.0%) @3.7x, remaining -5:-3 RBU  55.9% UBU  15.6%
 1382875136/0 (-118.7%) @3.6x, remaining -5:-5 RBU   5.9% UBU   7.0%
builtin_dd: 367392*2KB out @ average 3.3x1352KBps
/dev/sr1: flushing cache
/dev/sr1: closing track
:-[ CLOSE TRACK failed with SK=5h/INVALID FIELD IN CDB]: Input/output error
/dev/sr1: closing session
:-[ CLOSE SESSION failed with SK=5h/SESSION FIXATION ERROR - INCOMPLETE TRACK 
IN SESSION]: Input/output error
Command exited with non-zero status 5
0.13user 2.71system 2:54.60elapsed 1%CPU (0avgtext+0avgdata 35760maxresident)k
1470188inputs+0outputs (6major+8496minor)pagefaults 0swaps

        The resulting disk state:

READ TRACK INFORMATION[#2]:
 Track State:           invisible
 Track Start Address:   250496*2KB
 Next Writable Address: 676192*2KB
 Free Blocks:           1618912*2KB
 Track Size:            2044608*2KB
FABRICATED TOC:
 Track#1  :             17@0
 Track#AA :             17@248448
 Multi-session Info:    #1@0
READ CAPACITY:          248448*2048=508821504

        I guess I could try $ xorriso -close-damaged now to rectify?
        FWIW, the NWA now points to where the session should’ve ended:
        2048 logical blocks prior to where I intend to write the
        subsequent one.

        Regardless, it seems that there’s a bug in growisofs(1)
        triggered when seek= is in use.  Perhaps due to the number
        of blocks in a track being different to that actually written
        during the given run of growisofs(1)?

        Other than that, I’m loosely considering writing a dedicated
        dd(1)-like tool (with seek= /and/ skip=) for writing to
        optical media.

 >> Finally, I’ve used dmsetup(1) to create a block device that maps
 >> the copy of the data from the tail of the medium over the
 >> miswritten portion

 >> bash# dmsetup create -- sr0.fixed \
 >>          <(printf %s\\n "0 944640 linear /dev/sr0 0" \
 >>                "944640 1536 linear /dev/sr0 9153024" \
 >>                "946176 8198656 linear /dev/sr0 946176")

 > Now this is a stunt which I shall memorize.

 > I guess it would work with a second session on the DVD+R as well.

        Linux devmapper deals with block devices and block ranges,
        so it should be agnostic to the presense of sessions.

        That said, it may make sense to map inter-session gaps, as
        well as anything else that might end up giving read errors,
        to devmapper ‘zero’ target.

-- 
FSF associate member #7257  http://am-1.org/~ivan/