[Top][All Lists]

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

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

From: Jape Person
Subject: Re: [Bug-xorriso] Follow-Up on Burning Problems Debian Testing
Date: Mon, 24 Aug 2015 23:05:42 -0400
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Icedove/31.7.0

On 08/24/2015 04:29 PM, Thomas Schmitt wrote:

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

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.)


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
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

Have a nice day :)


Hi, Thomas.

That's a lot to digest. Mind is kind of muddled because of medications so will have to sort things out in my mind later -- probably at the end of the week.

Many thanks for your instructions. I will try to make the most of them.

Best regards,

reply via email to

[Prev in Thread] Current Thread [Next in Thread]