Re: [Bug-xorriso] BDXL support

[Johan de Jong]

Hi,

Just an update:

I have attempted to write another disc today (still failed to close the first one). It took two attempts as the first failed once again due to an (media) error. Unfortunately I failed to save the messages, but I remember that it failed already at the first 32 sectors. Also, there was a message that there was a failure to allocate a track of xxxx bytes. Replacing the disc with a fresh one proceeded ok, although it has not finished checking the MD5 digest yet.

So, with a succesrate of 50% in a, admittedly, small number of attempts it has been hit and miss so far. It seems unlikely that it has anything to do with the OS or the software, but rather the drive (firmware perhaps? It is very recent and I havent even found any downloadable files such as firmware or documentation on the LG sites yet) or the media.

I hope the succesrate will increase in the future otherwise this way of archiving important date becomes cumbersome and too expensive.

Have a nice day :-)

Johan

On Fri, Jan 15, 2016 at 1:21 PM, Johan de Jong <address@hidden> wrote:

Hi Thomas,

See my comments below.

Have a nice day :-)

On Thu, Jan 14, 2016 at 7:36 PM, Thomas Schmitt <address@hidden> wrote:

Hi,

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

Indeed. It's a proof of principle at the very least.

 

Johan de Jong wrote:

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

I think BDXL thus is a viable medium for archiving important data. I have two NAS systems (one 'online', one backup (done nightly instead of realtime so I have time to recover accidentally deleted data), but data that is really important to me I like to keep offline. M-discs media supposedly last long enough for the medium itself not to be the bottleneck (the risk is rather that the technology becomes obsolete at some point I suppose). DVD+R or DL would be too cumbersome for a few hundred of GiB and take up a lot of space (even on spindles). This suits me fine, although I prefer to write full backups (no selection, just everything including OS, backups of laptops and computers etc.) to LTO tape. Never rely on one medium alone they say. Paranoid aren't I? ;-)

 

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

That clarified a lot! It all makes sense now. Especially with regard to the order of processing the commands. I should probably have known if I read the manual top to bottom instead of picking what I thought I needed.

 

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

Understandable. It was rather cryptic, sorry. What I means to say was that only the MD5 digest of the image on the optical disc was being verified and not the MD5 digest of the individual files. The latter comes in handy when one wishes to know which files are still 'intact' and which ones aren't (barring damage to the filesystem data on the optical disc). You already addressed my ignorance in your examples, mentioning -check_md5_r. Thanks.

 

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

Suppose I could be of help? I could write a 'xorriso getting started' for example. The aim would be not to be a complete manual (we have the manpage for that), but rather describing the basic principles that some, or at least this was true for me, may fail to grasp when they start out using xorriso. The order of command executions for example. Covering the examples in your previous post and just basically guiding the user a bit more through the usage then the examples in the manpage do. Interested?

 

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

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

Indeed. This discs are rather expensive, so it is no fun. Could have been the medium or the fact that the drive and medium were still cold from arrival (4 degrees outside when it was delivered). But no, certainly no layer boundary (which are audible during burning by the way).

 

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

Indeed. But that is enough for me :-). Moreover, the DVD burning speed for M-disc DVD's is 4x DVD as well, so it would be much slower than 20x DVD. Supposedly for regular BD-R the drive should write at 16x BD speed near the edges of the disc.

 

> Ok, session data match recorded md5.

Looks good. Congrats.

Thanks. I'm rather happy it works, which we have you to thank for.

Now to figure out how to close the BD I wrote, without adding another session, if it is possible. Since -close "on" will cause the disc to be marked non appendable after the next write and there being no next write I may have painted myself into a corner :-D

 

--

Microsoft ... is that somekind of toiletpaper?

--

Microsoft ... is that somekind of toiletpaper?