bug-xorriso
[Top][All Lists]
Advanced

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

Re: [Bug-xorriso] To Thomas Schmitt: how to go on, xorriso is installed


From: Thomas Schmitt
Subject: Re: [Bug-xorriso] To Thomas Schmitt: how to go on, xorriso is installed
Date: Mon, 22 Apr 2019 12:01:47 +0200

Hi,

Adalbert Han├čen wrote:
> Also I checked the other bigger pile with a RW logo on them: They are all
> DVD+R.

Looking at my own DVD+R media ... indeed. Not very large "RW" and below
much smaller "DVD+R".
My DVD+RW media have the same "RW" logo and small DVD+ReWritable".

Must be some marketing thing. I never gave much notice because my
DVD+RW media have large texts "DVD+RW" above the "RW" logo.


> Media current: CD-RW
> Probably I should only use only xorriso to write onto this CD-RW because
> xfburn will finalize what is written to. I will not be able to add to the
> disc once I have written to it with xfburn - right?

Not with DVD+RW. Xfburn will accept it as blank and writable.

There are two families of media.

Sequential multi-session:
CD-R, unformatted, CD-RW, DVD-R, DVD+R, unformatted DVD-RW, and BD-R if
not formatted to "Pseudo Overwrite" or "Random Recording Mode".

Overwritable random read-write:
Formatted CD-RW, DVD-RAM, DVD+RW, formatted DVD-RW, BD-RE, BD-R formatted
to "Pseudo Overwrite" or "Random Recording Mode".

The sequential ones record multi-session information on hardware. They
can be blank, appendable, or closed. They prescribe a particular start
address for writing and would refuse on random access writing.

On hardware level, overwritable media are blank only when unformatted
and never closed. One can write to them at inearly any block address with
a granularity of 2 KiB or 32 KiB.
They do not record multi-session information on hardware level.
xorriso emulates multi-session by using the size information of the
ISO 9660 filesystems to form a chain of ISO 9660 sessions with similar
properties as on sequential media.

So it is an emulation if xorriso talks of "blank", "appendable", or
"closed" DVD+RW. "closed" is assumed if the medium content does not
look like an invalidaded ISO and does not begin by 64 KiB of zeros.
xorriso command -blank with DVD+RW is actualy just a write operation
which invalidates the ISO superblock or overwrites the first 64 KiB of
unknown data formats.

libburn classifies DVD+RW always as blank, because they need no blanking
for being written from scratch. Therefore Xfburn always sees them as
blank, too.

Overwritable media are nearly like data files on disk. So xorriso treats
a data file as emulated drive with overwritable medium. ZB.
  -dev "$HOME"/mein_image.iso

A USB stick may be used as overwritable medium too.
Either the whole device:
  -dev stdio:/dev/sdc
or a partition on it
  -dev stdio:/dev/sdc3
(Take care not to confuse the addresses of the stick and your system disks.)


> Is it right that the first writing to such a medium (i.e. on a blank medium)
> should be something like
>
> xorriso -for_backup \
> -dev /dev/sr0 \
> -volid 'selected volume id' \
> -map 'directory with all files to be written' /\
> -map 'directory with all other files to be written' /\
> -commit \
> -check_md5 fatal -- \
> -eject all

This looks ok for first session and further sessions alike.
Command -dev loads the existing ISO tree, if the medium is not "blank".
It also prepares for writing a new session. Either from scratch, if the
medium is "blank", or after the existing sessions, if it is "appendable".


> whereas all later sessions to be written have to be with -outdev like this:

No. -outdev does not read the ISO tree. Writing is then only allowed
to "blank" media.
Command -indev loads the tree without enabling writing.
The combination of both, -indev and -outdev, can point to two different
drives. If it points to the same drive, then it is equivalent to -dev.
Only then xorriso allows you to write to an "appendable" medium.


> is it really possible to change the volume id in later sesseions?

Yes. Each session has its own Volume Id.
Output of xorriso command -toc with one of my backup DVD+RW:

Media blocks : 2276160 readable , 18944 writable , 2295104 overall
TOC layout   : Idx ,  sbsector ,       Size , Volume Id
ISO session  :   1 ,        32 ,   1117739s , HOME_Z_2019_02_20_230304
ISO session  :   2 ,   1117792 ,     22473s , HOME_Z_2019_02_21_224132
ISO session  :   3 ,   1140288 ,     20491s , HOME_Z_2019_02_22_220733
...
ISO session  :  53 ,   2231168 ,     21877s , HOME_Z_2019_04_19_221045
ISO session  :  54 ,   2253056 ,     23096s , HOME_Z_2019_04_21_224356
Media summary: 54 sessions, 2275223 data blocks, 4444m data, 37.0m free

Two months of zisofs compressed incremental backups. The backup area
size on disk is about 4 GB. So this DVD+RW is worth 200 GB of flatly
repeated full backups.

I can mount any of the backup days by session number or Volume Id:

  $ sudo xorriso -osirrox on -mount /dev/sr0 volid '*2019_02_22*' /mnt/iso
  ...
  libisoburn: UPDATE : Found 54 ISO sessions by scanning 3456 kB in 6 seconds
  Volume id    : 'HOME_Z_2019_02_22_220733'
  Mount command: mount -t iso9660 -o nodev,noexec,nosuid,ro,sbsector=1140288 
'/dev/sr0' '/mnt/iso'

  Mounted session 3 of device '/dev/sr0' as directory '/mnt/iso'
  $

(This also works around the Linux bug which lets the drive pull in the
 motorized tray but immediately complains about seeing no medium.)

I may also mount two sessions for comparision, by tricking out the Linux
ban on double mounting a /dev/sr* device:

  $ sudo xorriso -osirrox on -mount_opts shared \
                 -mount /dev/sr0 volid '*2019_02_25*' /mnt/iso2
  ...
  Mount command: mount -t iso9660 -o 
loop,nodev,noexec,nosuid,ro,sbsector=1178720 '/dev/sr0' '/mnt/iso2'

  Mounted session 5 of device '/dev/sr0' as directory '/mnt/iso2'
  $

(Note the additional mount -o option "loop". Now it mounts /dev/loop0,
 not /dev/sr0. The kernel does not notice that loop0 is served by sr0.)


> However in the help of xorriso I read:
>    Creating, Growing, Modifying, Blind Growing:
>     A new empty ISO image gets created if there is no input drive
>     with a valid ISO 9660 image when the first time an output drive
>     is defined. This is achieved by command -dev on blank media or
>     by command -outdev on media in any state.
>
> If I take this verbatim, -outdev works on media in any state,

Yes and no. Read on:

     The new empty image  can  be  populated  with  directories  and  files.
     Before  it can be written, the medium in the output drive must get into
     blank state if it was not blank already.

So -outdev can acquire media in any state. If no -indev is acquired yet
it starts a new ISO image for composition and future writing.
If no directory tree was loaded yet from the -outdev medium (by -dev or
-indev), then it can be blanked.
Actual data writing is possible only on blank media, if not -indev or -dev
loaded an ISO directory tree from that same drive and medium.

About this loading:

     If there is a input drive with a valid ISO image, then this image  gets
     loaded as foundation for manipulations and extension. The constellation
     of input and output drive determines which write method will  be  used.
     They have quite different capabilities and constraints.

Next come descriptions of -dev (or -indev equal to -outdev) and of
-indev being a different drive than -outdev.

You want the method of "growing" (-dev) where the new session is written
as add-on to the same media from which the ISO image was loaded.
(If you want the other method, then you need to use a data file as
 second drive and later burn this file to a new medium.)


> I include the draft for what I want to add to the post.

I came to
  
http://www.ubuntu-forum.de/artikel/67814/xfburn-sch%C3%A4lgt-mit-fehlgeschlagen-burn-run-failed-fehl.html#post399560
which looks like your askubuntu question in german. I assume it is
from you. If not: Well, same problem, same solution.
So i wrote an answer in german.


> Application/VND.OASIS.OPENDOCUMENT.TEXT

Urm. Please export it as "ASCII" (actually UTF-8 nowadays) plain text
and send that plain text to me.


> Happy Easter

To you too.


Have a nice day :)

Thomas




reply via email to

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