Re: [Bug-xorriso] Follow-Up on Burning Problems Debian Testing

[Thomas Schmitt]

Hi,

> libburn : FATAL : SCSI error on write(268416,16): [3 0C 00] Medium error. 
> Write error.

Drive and medium did not like each other.
The burn programs have no share in this error.
They get it reported from the drive and can only
forward it to the user.

It happened at block 268416, i.e. about 500 MB after
start. The number of blocks in the failed WRITE
command was 16. "3 0C 00" is what the drive reported.
"Medium error" is the text associated with error key 3,
"Write error" is the text associated with the additional
code "0C 00".


> Writing to '/dev/sr0' completed successfully.
> ...
> Media status : is written , is appendable

Looks ok. The fact that generic xorriso classifies it as
"appendable" on DVD+RW indicates that it is recognized
as ISO 9660.

Nevertheless, do a checkread. Compute the MD5 of the
file 20150822chip.iso

  md5sum 20150822chip.iso

and then of the same amount of blocks from the DVD+RW

  blocks=$(expr $(ls -l 20150822chip.iso | awk '{print $5}') / 2048)
  dd if=/dev/sr0 bs=2048 count=$blocks | md5sum

(In general you should make ISOs with xorriso -for_backup,
 resp. xorriso -as mkisofs --for_backup. This will record
 MD5s of the written files and for the whole ISO.)

Note well that xorriso -as cdrecord will regard the DVD+RW as
"blank", because it does not need any blanking before it
can be written again. The "-as cdrecord" personality ignores
the size info presented by the ISO filesystem superblock.


> However, I noticed  that the burn speed was 4.0x all the way through this
> time, and on the first successful data burn to another DVD+RW disc. The burn
> speed throughout the unsuccessful try was 2.4x.

The drive decides about speed. The burn program can request
a particular performance, but the drive decides.
If it feels that the dye is not good, then it may reduce speed.

One known reason for failure-followed-by-success is to
store a written DVD+RW for several years and then re-use it.
I recently migrated to a new workstation and therefore
could recycle a spindle full of DVD+RW backups.
They did not throw write errors but several of them did
not yield the newly written data when checkreading. On the
second try they were ok.


> I have DVD+Rdl

Oh. DVD+R DL are early quitters, too. Even before DVD-RW do.

Nevertheless, let's try. We can only learn.

Use the same command as with DVD+RW. If there remains
much room unwritten and you might want to fill it up later,
then use now option -multi with xorriso -as cdrecord.
(With DVD+RW it makes no difference. But DVD+R without
 -multi get closed with no chance for further writing.)


> DVD-RW 

Better use them formatted. They seem to last longer and you
spare the plight of blanking them before re-use.
Do once per medium

  xorriso -outdev /dev/sr0 -format as_needed -eject all

(Sequence of generic xorriso commands matters. -outdev must
 come before -format.)
This will last as long as a full write run. Afterwards,
the medium should behave much like DVD+RW.

On the other hand, unformatted DVD-RW are read-only until
you blank them. It depends on your safety needs what is
considered more important.


> could try to figure out how to produce the .iso images
> without doing a two-step process.

That's actually the standard use case for generic xorriso
(i.e. neither -as mkisofs, nor -as cdrecord):

  cd /directory/with/tarballs
  xorriso -for_backup -outdev /dev/sr0 -blank as_needed -add my*many*.tar.gz --

The arguments are called "commands" in this mode.
They get executed in sequence like in a shell script.
Some have a fixed number of arguments (-for_backup has 0,
-outdev has 1) or a variable number (-add gets the expanded
list of tar.gz files). The latter get their argument list
terminated by '--'.
Command -blank "as_needed" tells xorriso to do what is
needed to make the medium writable from scratch. E.g.
blank used CD-RW or DVD-RW, or invalidate a ISO filesystem
that is found on DVD+RW.

Verify after burning by:

  xorriso -for_backup -indev /dev/sr0 -check_media --

This should report something like

  xorriso : UPDATE : Found matching MD5 superblock tag: start=0 size=18
  xorriso : UPDATE : 32 blocks read in 3 seconds , 0.0xD
  xorriso : UPDATE : Found matching MD5 tree tag: start=0 size=2060
  xorriso : UPDATE : 2816 blocks read in 4 seconds , 4.1xD
  ...
  xorriso : UPDATE : 158240 blocks read in 55 seconds , 4.9xD
  ...
  xorriso : UPDATE : 2275552 blocks read in 469 seconds , 10.2xD
  xorriso : UPDATE : 2282496 blocks read in 470 seconds , 10.2xD
  xorriso : UPDATE : Found matching MD5 session tag: start=0 size=2284974
  xorriso : UPDATE : 2285125 blocks read in 470 seconds = 7.2xD
  Media checks :        lba ,       size , quality
  Media region :          0 ,    2285125 , + good
  Media region :    2285125 ,       9979 , 0 untested
  MD5 checks   :        lba ,       size , result
  MD5 tag range:          0 ,    2284974 , + md5_match
  
Read errors or MD5 mismatches would cause loud error messages.
The ISO ends 20 MB before the end of the DVD+RW.
Thus these 9979 staid untested.

One can do more artful shaping by help of command -map.

If your backups leave room on the medium, then you might
be interested in incremental backups. I.e. a first fat
base backup and then smaller added sessions which make
changes to represent the newer backup states.

See the examples at the end of the much too long man page
of xorriso.
- "Blank medium and compose a new ISO image as batch run"
  shows a more complicated composition.
- "Manipulate an existing ISO image on the same medium"
  shows how to add, rename or remove (hide) files by an
  addon session.
- "Incremental backup of a few directory trees"
  together with the additional commands
        -hardlinks perform_update \
        -find / -type f -pending_data -exec set_filter --zisofs -- \
  would be a sincere competitor to your .tar.gz archives.
  Debian has zisofs reading enabled in the kernel by default.
  .tar.gz can become quite inconvenient when it comes to
  restoring single files.
  This example also shows how to checkread in the same
  xorriso run that wrote the new session.


And then there is
  http://scdbackup.sourceforge.net/main_eng.html
for those backups which do not fit onto a single medium.
It is some effort to configure, because you need to make
some decisions before the fun can start.
But then it plans for the particular volumes of the backup,
produces the ISOs and burns them, one by one.
See also
  http://scdbackup.sourceforge.net/examples.html


Have a nice day :)

Thomas