Re: [Bug-xorriso] BDXL support

[Thomas Schmitt]

Hi,

(i Cc address@hidden because this might be of general
 interest)

Johan de Jong wrote:
> I was finally able to test BDXL burning as my drive and media arrived today:
> Drive: LG BH16NS55
> Media: Verbatim M-Disc BDXL
> I'm happy to report that burning succeeded!
> The first attempt failed due to media error though. 
> ...
> Media current: BD-R sequential recording
> Media product: VERBAT/IMk/0 , Mitsubishi Kagaku Media Co.
> Media status : is blank
> Media blocks : 0 readable , 48878592 writable , 48878592 overall
> ...
> Format status: unformatted, up to 95466.0 MiB
> Format idx 0 : 00h , 47305728s , 92394.0 MiB
> Format idx 1 : 32h , 47305728s , 92394.0 MiB
> Format idx 2 : 32h , 30790656s , 60138.0 MiB
> Format idx 3 : 32h , 48092160s , 93930.0 MiB
> ...
> Write speed L:   8992k ,  2.0xB
> Write speed H:  17984k ,  4.0xB

100,103,356,416 bytes. Impressive.


> address@hidden:~$ xorriso -for_backup -disk_dev_ino on -dev /dev/sr1
> -volid BACKUP_FOTOS_001_0001_2701 -map Temp_burn / -commit -toc
> -check_md5 FAILURE -- -eject all -close on

> Funny thing remains that eventhough I used "-close on" the media is still
> reported as being appendable.

That's because you set -close to "on" only after burning
has already happened. Be aware that the xorriso commands are
performed in the given sequence, like commands of a shell script.

In particular:

-for_backup enables production and reading of MD5, ACL, xattr,
and hardlink relations.

-disk_dev_ino enables recording and reading of inode numbers
of disk files. This is a preparation for the next incremental
add-on session, which you actually do not plan. (So you may leave
out this command if you use -close "on".)

-dev acquires the drive and creates an empty ISO filesystem
model object because no ISO is on the medium. If there was an
ISO 9660 filesystem, then -dev would load its ISO metadata into
the model object so you manipulate the directory tree.

-volid prepares in the model object the disk label for the
upcomming ISO production.

-map inserts a copy of a disk directory tree into the model object.

-commit triggers ISO filesystem production and burning to the
target given by -dev.

-toc shows the new content table of the target after burning.

-check_md5 checks the most recent session by its MD5.

-eject tries to unload the tray (if it has a motor) and gives
up the drive.

After all this happened, -close "on" says that the medium shall
be closed by the next burn run. But there happens no next run
before the program ends.

So this would probably be what you want:

  xorriso \
     -for_backup \
     -close on \
     -dev /dev/sr1 \
     -volid BACKUP_FOTOS_001_0001_2701 \
     -map Temp_burn / \
     -commit \
     -toc \
     -check_md5 FAILURE -- \
     -eject all

(Of course you can leave out the backslashes and newlines in
order to submit this as one single command line. In a script,
this multi-line form is more easy to read and to edit.)


> I have nog figurered out yet how to test the backup again at a later time.

Use the same command -check_md5 after loading the existing ISO's
metadata. Command -for_backup before -indev causes MD5 and other
extras to be loaded by -indev:

  xorriso -for_backup -indev /dev/sr1 -check_md5 FAILURE --

On a multi-session medium, this only checks the most recent session.
To check the whole medium with all sessions, use

  xorriso -for_backup -indev /dev/sr1 -check_media --

To check all data files which are reachable by the directory
tree of the most recent session, use

  xorriso -for_backup -indev /dev/sr1 -check_md5_r SORRY / --

(Note the "_r" with -check_md5_r and the additional parameter "/"
 in comparison to the first example.)

In all three examples, -indev will fail if the MD5 of the directory
tree of the most recent session does not match. In that case you may
still get an overview of the damage in older sessions by

  xorriso -for_backup -outdev /dev/sr1 -check_media use=outdev --


> Also, the test was based on the filesystem image on
> disc rather than testing the files themselves.

I do not grasp what this statement means.
Please clarify.


> The manual page is sometimes a bit hard to figure out.

It contains many layers of editing. The goal to document all
technical details conflicts with the goal to provide an
introduction or tutorial.

--------------------------------------------------------------

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

Now that's pathetic. Not even 1 percent written.
But surely not a problem particular to the multiple layers
of a 100 MB BD-R.

The medium was not formatted. So no Defect Management happened.
If you let xorriso format the blank BD-R before you start burning
  ...
  -dev /dev/sr1 \
  -format as_needed \
  -volid BACKUP_FOTOS_001_0001_2701 \
  ...
then you get checkreading and replacement of bad blocks.
The price is half speed, or even slower. The benefit is
questionable.

To my experience, burning with Defect Management fails as
often as burning without Defect Management. It just needs longer
and makes more miserable noises.
I normally enable it only with media which shall take many small
sessions, where speed does not matter much.

The decision to format must be made as long as the medium
is blank. Written BD-R cannot be formatted any more.


> xorriso : UPDATE : Thank you for being patient. Working since 5437 seconds.
> ISO image produced: 46695821 sectors

Nearly 17 MiB/s. 3.82 x BD speed. 12 x DVD.
So one could say it just saves you the plight of inserting about 20
DVD-R into a "20x" burner. (They begin to burn at 6x or 8x and get
faster until the end.)


> Ok, session data match recorded md5.

Looks good. Congrats.


Have a nice day :)

Thomas