Linux - GeneralThis Linux forum is for general Linux questions and discussion.
If it is Linux Related and doesn't seem to fit in any other forum then this is the place.
Notices
Welcome to LinuxQuestions.org, a friendly and active Linux Community.
You are currently viewing LQ as a guest. By joining our community you will have the ability to post topics, receive our newsletter, use the advanced search, subscribe to threads and access many other special features. Registration is quick, simple and absolutely free. Join our community today!
Note that registered members see fewer ads, and ContentLink is completely disabled once you log in.
If you have any problems with the registration process or your account login, please contact us. If you need to reset your password, click here.
Having a problem logging in? Please visit this page to clear all LQ-related cookies.
Get a virtual cloud desktop with the Linux distro that you want in less than five minutes with Shells! With over 10 pre-installed distros to choose from, the worry-free installation life is here! Whether you are a digital nomad or just looking for flexibility, Shells can put your Linux machine on the device that you want to use.
Exclusive for LQ members, get up to 45% off per month. Click here for more info.
>>>>> Then let us burn some directory content from hard disk to DVD-RW.
>>>>> Assumed that its path is "$HOME"/files_for_dvd and that its name on the
>>>>> DVD shall be /files1, that would be:
[code]
>>>>> dir_on_disk="$HOME"/files
>>>>> dir_in_iso=/files1
Actually "dir_..." is a bit misleading variable name, because in this
case you deal with a data file, not with a directory full of files and
sub directories.
In the end the proposed command is the same as:
Thanks again for your long understanding and help. I looked over the material you gave me and discovered the xorriso iso data disc needs to be ejected and re-inserted before the data becomes available. Thanks for that appended side note because until I discovered it I was once again going in circles :-)
> looked over the material you gave me and discovered the xorriso
> iso data disc needs to be ejected and re-inserted before the data
> becomes available.
The problem is that the Linux kernel does not know about the new content
of the DVD-RW. (It can learn parts without being aware and that confuses
it even more.)
xorriso can read and show the new content of the DVD-RW, because it lets
libburn talk to the drive with the kernel being only the postman who
carries SCSI commands to the drive and replies from the drive.
The only reliable way to cause the kernel to re-assess the new state of
the DVD-RW is to eject and re-load it. This makes Linux curious and lets
it read the info about the medium and its content.
when an first back_up ISO is created; then changes are made to the material held within the first back_up ISO, then these changes are backed_up - is an second ISO created or is the first ISO updated or is the first ISO over written with the changes?
also: when an ISO is created of an directory on disk which has its own directory tree with files within this directory tree is the complete directory structure created within the newly created ISO?
This invalidates the old sessions and makes the medium ready for writing
a new session 1 over the data blocks of the old sessions.
Blanking works only on re-usable media. Not on CD-R, DVD-R, DVD+R, or
BD-R.
Another way of writing is to "append" a new "session". The data of
previous sessions do not get overwritten, but a new superblock and
directory tree get written which become the new default mount point.
This new tree will show old files and new files together.
But if a new file has the same path as an old file, it has precedence
over the old file.
To append a session you need to acquire the drive by command -dev rather
than -outdev, so that the old directory tree gets loaded as base of the
new directory tree.
Further you need to avoid command -blank.
Linux and FreeBSD are able to mount older sessions if appropriate options
are used for program mount.
xorriso can tell the start block number which mount needs to find the
older superblock.
For example, i have a BD-RE medium for daily backup. Currently it
covers 74 days. The way how it is done is shown in man xorriso example
"Incremental backup of a few directory trees".
Code:
$ xorriso -outdev /dev/sr0 -toc
...
TOC layout : Idx , sbsector , Size , Volume Id
ISO session : 1 , 32 , 2112020s , HOME_2019_11_24_152510
ISO session : 2 , 2112064 , 68114s , HOME_2019_11_25_160120
ISO session : 3 , 2180192 , 77406s , HOME_2019_11_26_154114
...
ISO session : 47 , 4789248 , 58628s , HOME_2020_01_09_160431
...
ISO session : 72 , 5983904 , 45533s , HOME_2020_02_03_190255
ISO session : 73 , 6029440 , 45761s , HOME_2020_02_04_162128
ISO session : 74 , 6075232 , 46874s , HOME_2020_02_05_155612
Media summary: 74 sessions, 6121007 data blocks, 11.7g data, 11.4g free
If i want to see the state of session 47 of January 9, i can perform
on Linux:
Code:
$ sudo mount -o sbsector=4789248 /dev/sr0 /mnt/iso
mount: /dev/sr0 is write-protected, mounting read-only
$ df /mnt/iso
Filesystem 1K-blocks Used Available Use% Mounted on
/dev/sr0 117256 117256 0 100% /mnt/iso
$ du -s /mnt/iso 2>/dev/null
4066177 /mnt/iso
So the command "df" shows a size of 117256 KB = 58628 blocks.
That's the size of the session.
But the sum of sizes of reachable data files by "du -s" is 4,066,177 KB.
That's because the still valid files of the 46 older sessions are
reachable.
Have a nice day
Thomas
Last edited by scdbackup; 02-05-2020 at 12:36 PM.
Reason: Posted older version of text by mistake
This invalidates the old sessions and makes the medium ready for writing
a new session 1 over the data blocks of the old sessions.
Blanking works only on re-usable media. Not on CD-R, DVD-R, DVD+R, or
BD-R.
Another way of writing is to "append" a new "session". The data of
previous sessions do not get overwritten, but a new superblock and
directory tree get written which become the new default mount point.
This new tree will show old files and new files together.
But if a new file has the same path as an old file, it has precedence
over the old file.
To append a session you need to acquire the drive by command -dev rather
than -outdev, so that the old directory tree gets loaded as base of the
new directory tree.
Further you need to avoid command -blank.
Linux and FreeBSD are able to mount older sessions if appropriate options
are used for program mount.
xorriso can tell the start block number which mount needs to find the
older superblock.
For example, i have a BD-RE medium for daily backup. Currently it
covers 74 days. The way how it is done is shown in man xorriso example
"Incremental backup of a few directory trees".
Code:
$ xorriso -outdev /dev/sr0 -toc
...
TOC layout : Idx , sbsector , Size , Volume Id
ISO session : 1 , 32 , 2112020s , HOME_2019_11_24_152510
ISO session : 2 , 2112064 , 68114s , HOME_2019_11_25_160120
ISO session : 3 , 2180192 , 77406s , HOME_2019_11_26_154114
...
ISO session : 47 , 4789248 , 58628s , HOME_2020_01_09_160431
...
ISO session : 72 , 5983904 , 45533s , HOME_2020_02_03_190255
ISO session : 73 , 6029440 , 45761s , HOME_2020_02_04_162128
ISO session : 74 , 6075232 , 46874s , HOME_2020_02_05_155612
Media summary: 74 sessions, 6121007 data blocks, 11.7g data, 11.4g free
If i want to see the state of session 47 of January 9, i can perform
on Linux:
Code:
$ sudo mount -o sbsector=4789248 /dev/sr0 /mnt/iso
mount: /dev/sr0 is write-protected, mounting read-only
$ df /mnt/iso
Filesystem 1K-blocks Used Available Use% Mounted on
/dev/sr0 117256 117256 0 100% /mnt/iso
$ du -s /mnt/iso 2>/dev/null
4066177 /mnt/iso
So the command "df" shows a size of 117256 KB = 58628 blocks.
That's the size of the session.
But the sum of sizes of reachable data files by "du -s" is 4,066,177 KB.
That's because the still valid files of the 46 older sessions are
reachable.
Have a nice day
Thomas
thank you thomas, great information and detail, and it gives me a base to work from as i grapple with xorriso.
i'm beginning to grasp xorriso's fantastic capabilities. below is the iso (/Documents/xorriso). dragged and dropped a file from text editor into folder xorriso. the experience of opening this iso and discovering all the pieces were there is fantastic is an understatement as to my delight.
i should mention that a ISO 9660 session produces quite some overhead
on the medium.
It is advisable to bundle file changes in one session instead of writing
a session for each changed file.
The overhead consists of a superblock (in ISO 9660 terms: System Area and
Volume Descriptors), of a complete directory tree, of padding, and of
alignment.
The superblock and its alignment cost 64 KiB.
The size of the directory tree depends on the number of files, the length
of their names, and the amount of attributes which they have on hard disk.
Padding is a precaution against a Linux bug which actually only gets
triggered by CD media written with write type Track-At-Once. But it is
tradition to write 300 KiB of zeros at the end of each session.
Just as sacrifice for Ye Olde Bugge.
You may disable padding by xorriso command
Code:
-padding 0
The block number for the start of the next session is aligned to the
next full 64 KiB on overwritable media: DVD-RAM, DVD+RW, BD-RE, formatted
DVD-RW, block devices, or data files.
On sequential media this gap depends on the type:
BD-R aligns to the next full 64 KiB. DVD+R adds about 4 MiB.
DVD-R and unformatted DVD-RW create a large gap after the first session
and about 15 MiB after further sessions.
In summary:
Session overhead may range from a few hundred KiB to dozens of MiB.
But it is tradition to write 300 KiB of zeros at the end of each session.
Just as sacrifice for Ye Olde Bugge.
You may disable padding by xorriso command > -padding 0
is it your position the traditional 300KiB is an over-kill for Ye Olde Bugge.
since it's only triggered by CD media written with write type Track-At_Once is this an type write process common to users like me?
also: when xorriso is run and xorriso media is loaded in the sr0 tray and the sr0 tray closed xorriso fails and complains sr0 is busy i.e mounted. when the tray is open xorriso completes the process closing the tray itself before writing. is it possible to include an umount directive with the xorriso command?
I suppose umount -v /dev/dvd may run prior to running xorriso.
Last edited by wayne1937; 02-06-2020 at 09:59 PM.
Reason: Added: umount
> is it your position the traditional 300KiB is an over-kill for Ye Olde Bugge.
In principle yes, because its reason-to-be is in the CD TAO Read-Ahead
bug of Linux (and maybe other operating systems). The bug is triggered
by about 75 % of all drives which report the two trailing Run-out blocks
of a TAO track as readable. This is not wrong but misleading, because
these blocks can only be read by command READ CD, not by the usual data
read command READ.
The effect is that Linux believes to have more blocks readable than its
READ command can access. That would not be too bad, if not the kernel would
read in larger chunks, believe in a damaged CD, and give up without trying
to read a smaller chunk of blocks.
Padding helps by moving the ambiguous 2 blocks far away from the last
block in which the operating system's ISO 9660 driver would be interested.
The padding size of 300 KB stems from a wrong theory by the author of
cdrecord, who assumed that the problem would be in the 300 KB gap that
is created by the drives between two CD TAO tracks.
The truely needed padding size depends on the size of the operating system
read chunks. My own experiments indicate that 64 KiB are not always enough
but 128 KiB suffices.
Given all this mess and the tradition of adding 300 KiB, i better stay
with this but advise people to use -padding 0 if session overhead does
truely matter and if the medium is not CD written by type TAO.
There is the other wrte type Disc-At-Once (DAO) which does not write
Run-out blocks and thus avoides to trigger the Linux bug.
> is it possible to include an umount directive with the xorriso command?
Umounting is not a trivial task if all possible situations shall be
taken into account. Further the program would need superuser authority
in order to be able to unmount.
So i refrain from umounting automatically (as growisofs tries to do)
and leave it to the user to keep the hyperactive udisks2 from occupying
the drive.
> when the tray is open xorriso completes the process closing the tray
> itself before writing.
There are automounter versions which ignore the attempt of xorriso to
reserve the drive. They mount while xorriso is preparing for the write
run. The consequences can be quite confusing when Linux works with what
it read at mount time and the medium already has new content and size.
So i advise to either disable automounting of /dev/sr* devices or to
load manually, to wait until the drive blinking stops, and to unmount
the device manually.
Making bootable ISOs is more demanding. You need bootloader, operating
system, some fancy desktop, and more, which you pack up as ISO 9660 image.
For the last step of ISO 9660 production see: https://wiki.debian.org/RepackBootableISO
attempted to run xorriso ISO code as executable file. file created with vim and saved as xorriso.sh file made executable using chmod +x xorriso.sh attempted to run file: ./xorriso.sh result offered below:
LinuxQuestions.org is looking for people interested in writing
Editorials, Articles, Reviews, and more. If you'd like to contribute
content, let us know.
