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