Problem with growisofs -- cannot write multisession DVDs without ejecting and reloading tray

[Richardson, Eric J]

I am hoping that someone can help me with my growisofs problem. It's not really a Debian problem, but the author:
http://fy.chalmers.se/~appro/linux/DVD+RW/
suggests I start here anyway.

I have a (relatively new) server that we used to run Solaris 10 update 7 on. On this system, we would perform backups of certain log files every day to DVD. For this, we used:

growisofs -Z /dev/rdsk/c0t0d0s0 -R -f <files>

for the first write, and

growisofs -M /dev/rdsk/c0t0d0s0 -R -f <files>

For subsequent writes. We never had to eject the tray until we were ready to take it out, which is good, because there is no way to automatically reload the tray once it has ejected on this server, as on most servers. It worked swimmingly, as it always had on our other systems. For reference, on Solaris 10 we were using growisofs 7.1, and mkisofs 2.0.1.

Now we are in the process of moving to Red Hat 6.6. I don't think there's anything special about Red Hat, as I was able to duplicate the problem on Slackware 14.1, but that's the system we are trying to work with. Since I'd heard about troubles with the 'genisoimage' program that ships with Red Hat (and Debian, and Ubuntu), I went ahead and downloaded a cdrtools RPM from this helpful fellow:
http://negativo17.org/cdrtools/
and I also removed the 'fake' cdrtools that comes with Red Hat, just to be safe. So, now we are using Red Hat with a kernel of:
Linux 2.6.32-504.8.1.el6.x86_64

Mkisofs is:
mkisofs 3.01a27 (x86_64-unknown-linux-gnu) Copyright (C) 1993-1997 Eric Youngdale (C) 1997-2015 Joerg Schilling

Growisofs is:
* growisofs by <***@fy.chalmers.se>, version 7.1,
front-ending to mkisofs: mkisofs 3.01a27 (x86_64-unknown-linux-gnu) Copyright (C) 1993-1997 Eric Youngdale (C) 1997-2015 Joerg Schilling

And, in case you were curious, cdrecord is:
Cdrecord-ProDVD-ProBD-Clone 3.01a27 (x86_64-unknown-linux-gnu) Copyright (C) 1995-2015 Joerg Schilling

The DVD drive in question is reported by cdrecord -scanbus as:
'Optiarc ' 'BD RW BD-5750H ' '1.00' Removable CD-ROM

Unfortunately I cannot confirm this by physically inspecting the drive as I can't do so with the server where it is right now. But, like I said, it worked on Solaris 10 update 7, so it can't be TOO alien.

The physical media are JVC DVD-R 16X discs, off a big ol' spindle that says 'For Professional Use.' I don't think they would have a case if I used them in an unprofessional capacity. We use these media specifically because we have never had a problem with them and, as I said, the same media work fine on Solaris 10.

Volume management (or autofs) is not running, and all commands are run as root.

Here is how the disk looks to dvd+rw-mediainfo before I write anything to it:
INQUIRY: [Optiarc ][BD RW BD-5750H ][1.00]
GET [CURRENT] CONFIGURATION:
Mounted Media: 11h, DVD-R Sequential
Media ID: TYG03
Current Write Speed: 8.0x1385=11080KB/s
Write Speed #0: 6.0x1385=8310KB/s
Write Speed #1: 4.0x1385=5540KB/s
Write Speed #2: 2.0x1385=2770KB/s
Write Speed #3: 8.0x1385=11080KB/s
Speed Descriptor#0: 09/2298495 ***@8.0x1385=11080KB/s ***@8.0x1385=11080KB/s
Speed Descriptor#1: 00/2298495 ***@8.0x1385=11080KB/s ***@6.0x1385=8310KB/s
Speed Descriptor#2: 00/2298495 ***@4.0x1385=5540KB/s ***@4.0x1385=5540KB/s
Speed Descriptor#3: 00/2298495 ***@2.5x1385=3463KB/s ***@2.0x1385=2770KB/s
READ DVD STRUCTURE[#10h]:
Media Book Type: 00h, DVD-ROM book [revision 0]
Legacy lead-out at: 2298496*2KB=4707319808
READ DVD STRUCTURE[#0h]:
Media Book Type: 25h, DVD-R book [revision 5]
Last border-out at: 0*2KB=0
READ DISC INFORMATION:
Disc status: blank
Number of Sessions: 1
State of Last Session: empty
"Next" Track: 1
Number of Tracks: 1
READ TRACK INFORMATION[#1]:
Track State: invisible incremental
Track Start Address: 0*2KB
Next Writable Address: 0*2KB
Free Blocks: 2297888*2KB
Track Size: 2297888*2KB
READ CAPACITY: 0*2048=0

Looks blank to me! The only problem I can see with the way we write to DVD is I now have to tell growisofs not to eject the tray. I write the first session like so:
growisofs -Z /dev/sr0 -use-the-force-luke=notray -R -f file1file1file1_REDHAT.txt file2file2file2_REDHAT.txt file3file3file3_REDHAT.txt
Executing 'mkisofs -R -f file1file1file1_REDHAT.txt file2file2file2_REDHAT.txt file3file3file3_REDHAT.txt | builtin_dd of=/dev/sr0 obs=32k seek=0'
Setting input-charset to 'UTF-8' from locale.
Total translation table size: 0
Total rockridge attributes bytes: 503
Total directory bytes: 0
Path table size(bytes): 10
Max brk space used 0
178 extents written (0 MB)
/dev/sr0: "Current Write Speed" is 8.2x1352KBps.
builtin_dd: 192*2KB out @ average infx1352KBps
/dev/sr0: flushing cache
/dev/sr0: updating RMA
/dev/sr0: closing session

Other than using a Linux-style block device, this is how it has always looked. Now I will try to mount the media:
mount -o ro /dev/sr0 -t iso9660 /media/
mount: wrong fs type, bad option, bad superblock on /dev/sr0,
missing codepage or helper program, or other error
In some cases useful info is found in syslog - try
dmesg | tail or so

Nice! If I leave off the filesystem type, it complains, although it does not require a filesystem type at any other time. Here is what dvd+rw-mediainfo says:
GET [CURRENT] CONFIGURATION:
Mounted Media: 11h, DVD-R Sequential
Media ID: TYG03
Current Write Speed: 8.0x1385=11080KB/s
Write Speed #0: 6.0x1385=8310KB/s
Write Speed #1: 4.0x1385=5540KB/s
Write Speed #2: 2.0x1385=2770KB/s
Write Speed #3: 8.0x1385=11080KB/s
Speed Descriptor#0: 09/2298495 ***@8.0x1385=11080KB/s ***@8.0x1385=11080KB/s
Speed Descriptor#1: 00/2298495 ***@8.0x1385=11080KB/s ***@6.0x1385=8310KB/s
Speed Descriptor#2: 00/2298495 ***@4.0x1385=5540KB/s ***@4.0x1385=5540KB/s
Speed Descriptor#3: 00/2298495 ***@2.5x1385=3463KB/s ***@2.0x1385=2770KB/s
READ DVD STRUCTURE[#10h]:
Media Book Type: 00h, DVD-ROM book [revision 0]
Legacy lead-out at: 2298496*2KB=4707319808
READ DVD STRUCTURE[#0h]:
Media Book Type: 25h, DVD-R book [revision 5]
Last border-out at: 0*2KB=0
READ DISC INFORMATION:
Disc status: appendable
Number of Sessions: 2
State of Last Session: empty
"Next" Track: 2
Number of Tracks: 2
READ TRACK INFORMATION[#1]:
Track State: complete incremental
Track Start Address: 0*2KB
Free Blocks: 0*2KB
Track Size: 65264*2KB
Last Recorded Address: 191*2KB
READ TRACK INFORMATION[#2]:
Track State: invisible incremental
Track Start Address: 93952*2KB
Next Writable Address: 93952*2KB
Free Blocks: 2203936*2KB
Track Size: 2203936*2KB
FABRICATED TOC:
Track#1 : ***@0
Track#AA : ***@192
Multi-session Info: #***@0
READ CAPACITY: 192*2048=393216

It sure does look like it can see it! But I can't mount the disc. If I now eject the disc, and re-load the tray, I can mount it just fine, and see the files on it. Dvd+rw-mediainfo reports exactly the same information it did before I reloaded the tray. I will now write a second session to the disc:
growisofs -use-the-force-luke=notray -M /dev/sr0 -R file4file4file4_REDHAT.txt file5file5file5_REDHAT.txt file6file6file6_REDHAT.txt
Executing 'mkisofs -C 16,93952 -M /dev/fd/3 -R file4file4file4_REDHAT.txt file5file5file5_REDHAT.txt file6file6file6_REDHAT.txt | builtin_dd of=/dev/sr0 obs=32k seek=5872'
Setting input-charset to 'UTF-8' from locale.
ISO-9660 image includes checksum signature for correct inode numbers.
SUSP signatures version 1 found
Rock Ridge signatures version 1 found
Rock Ridge id 'RRIP_1991A'
Total translation table size: 0
Total rockridge attributes bytes: 821
Total directory bytes: 0
Path table size(bytes): 10
Max brk space used 0
178 extents written (0 MB)
/dev/sr0: "Current Write Speed" is 8.2x1352KBps.
builtin_dd: 192*2KB out @ average infx1352KBps
/dev/sr0: flushing cache
/dev/sr0: updating RMA
/dev/sr0: closing session

I can now mount the media with:
mount /dev/sr0 /media

But I can only see the first session on the disk (i.e., file1, file2, and file3, but not file4, file5, or file6). If I perform a dvd+rw-mediainfo, I get:
INQUIRY: [Optiarc ][BD RW BD-5750H ][1.00]
GET [CURRENT] CONFIGURATION:
Mounted Media: 11h, DVD-R Sequential
Media ID: TYG03
Current Write Speed: 8.0x1385=11080KB/s
Write Speed #0: 6.0x1385=8310KB/s
Write Speed #1: 4.0x1385=5540KB/s
Write Speed #2: 2.0x1385=2770KB/s
Write Speed #3: 8.0x1385=11080KB/s
Speed Descriptor#0: 09/2298495 ***@8.0x1385=11080KB/s ***@8.0x1385=11080KB/s
Speed Descriptor#1: 00/2298495 ***@8.0x1385=11080KB/s ***@6.0x1385=8310KB/s
Speed Descriptor#2: 00/2298495 ***@4.0x1385=5540KB/s ***@4.0x1385=5540KB/s
Speed Descriptor#3: 00/2298495 ***@2.5x1385=3463KB/s ***@2.0x1385=2770KB/s
READ DVD STRUCTURE[#10h]:
Media Book Type: 00h, DVD-ROM book [revision 0]
Legacy lead-out at: 2298496*2KB=4707319808
READ DVD STRUCTURE[#0h]:
Media Book Type: 25h, DVD-R book [revision 5]
Last border-out at: 0*2KB=0
READ DISC INFORMATION:
Disc status: appendable
Number of Sessions: 3
State of Last Session: empty
"Next" Track: 3
Number of Tracks: 3
READ TRACK INFORMATION[#1]:
Track State: complete incremental
Track Start Address: 0*2KB
Free Blocks: 0*2KB
Track Size: 65264*2KB
Last Recorded Address: 191*2KB
READ TRACK INFORMATION[#2]:
Track State: complete incremental
Track Start Address: 93952*2KB
Free Blocks: 0*2KB
Track Size: 192*2KB
Last Recorded Address: 94143*2KB
READ TRACK INFORMATION[#3]:
Track State: invisible incremental
Track Start Address: 100304*2KB
Next Writable Address: 100304*2KB
Free Blocks: 2197584*2KB
Track Size: 2197584*2KB
FABRICATED TOC:
Track#1 : ***@0
Track#2 : ***@93952
Track#AA : ***@94144
Multi-session Info: #***@93952
READ CAPACITY: 94144*2048=192806912

dvd+rw-mediainfo "knows" that I wrote a new track, but I can't see the new data when I mount the disk. If I eject the disc and re-load the tray, I can see the data just fine.

So, I can't write a multisession DVD on Linux without reloading the tray, though I could on Solaris 10. This problem does not appear on all drives, but it does on two of the three systems we have tested it on. I have tried:
blockdev --flushbufs --rereadpt /dev/sr0

and I have tried writing a C program that does an:
ioctl(fd, CDROMRESET)

and I have tried:
cdrecord -reset dev=0,0,0

All to no avail. I had read that this was a problem with kernels older than 2.6.8, but we are using 2.6.32, and anyway, I can repeat the problem on Slackware using kernel 3.10.17. Am I missing something?

Any help is appreciated.

Thanks,
-Eric J. Richardson

[Thomas Schmitt]

Hi,

the problem you describe is caused by the Linux block
device driver not being aware of the changes on the DVD
which were made via the Linux generic SCSI driver.
growisofs normally fights this by its finger biting
unload-reload cycle, which forces the block device
driver to re-assess the medium.
dvd+rw-mediainfo uses the SCSI driver and thus shows
you the current media state even without reloading.

There is not much hope for a remedy about mount(8)
unless Linux offers an opportunity to re-assess the
medium without loading. growisofs.c shows traces of
Andy's fight against the kernel's ignorance. E.g.
" * - Linux: deploy BLKFLSBUF to avoid media reloads when possible;"

Another negative effect of this situation is that
growisofs employs mkisofs (or a clone or an emulation)
which reads the disc by the block device driver and
thus can get to see outdated buffered disc state.
But other than with mount(8) the user space program has
a choice between the two rivaling drivers.

libisoburn resp. its application xorriso read via the
SCSI driver and thus get to see the current disc content.
content.

So xorriso can do multi-session without reload.
First session (like growisofs -Z):

xorriso -outdev /dev/sr0 -blank as_needed -follow link \
-add file1file1file1_REDHAT.txt file2file2file2_REDHAT.txt \
file3file3file3_REDHAT.txt --

Further session (like growisofs -M):

xorriso -dev /dev/sr0 -follow link \
-add file4file4file4_REDHAT.txt file5file5file5_REDHAT.txt \
file6file6file6_REDHAT.txt --


As said, the problem of mount(8) remains, because the
ISO 9660 filesystem driver relies on the block device
driver.
xorriso can copy files out of not mounted ISO filesystems

xorriso -osirrox on -indev /dev/sr0 \
-extract /file4file4file4_REDHAT.txt \
"$HOME"/file4file4file4_REDHAT.txt \
-extract /some/directory/tree \
"$HOME"/tree_from_iso

---------------------------------------------------------
Proposal for mount(8) and multi-session by different media:

If you can use DVD+RW, then it would be possible to
perform all write and read traffic by the block device
driver. DVD-R and DVD+R cannot be written that way.

To let xorriso use the block device driver, prepend
"stdio:" to the drive address with above xorriso runs:

xorriso -outdev stdio:/dev/sr0 ...

resp.

xorriso -dev stdio:/dev/sr0 ...

xorriso will emulate a table-of-content and thus allow
to access the older sessions by Linux mount(8) option
-o sbsector=$block_address.
Its own read facility can be directed to older sessions
by
-load session $number -indev ...
or
-load sbsector $block_number -indev ...
or
-load volid $search_pattern -indev ...

With small sessions, DVD+RW have a substantial capacity
advantage over DVD-R, because the latter put gaps of
more than 10 MiB between sessions. The waste after the
first session is even larger. In your last dvd+rw-mediainfo
output one can read:
Track Start Address: 0*2KB
Track Size: 65264*2KB
Track Start Address: 93952*2KB
Track Size: 192*2KB
Next Writable Address: 100304*2KB
Multi-session emulation of libisoburn on DVD+RW only
pads up to the next full multiple of 64 KiB.

The number of sessions on DVD-R is restricted to 99,
on DVD+R the limit is 153.
On DVD+RW, the number is only limited by the data
storage capacity of the medium. But dvd+rw-mediainfo
will show only one session, because the hardware has
only one single logical track.
Use

xorriso -indev /dev/sr0 -toc

to get a list of ISO 9660 sessions.

---------------------------------------------------------
(Rant zone)

Post by Richardson, Eric J
Am I missing something?

Not you. But the Linux kernel developer community does.
It offers drivers for about any exotic device, but
it does not care for coordination between driver
levels or for a decent performance of the SCSI driver
when more than one burn run is active.

Said that, i have to state that the other free operating
systems show no better overall quality with handling
optical media.
Their ISO 9660 filesystem drivers are all inferior to Linux.
Solaris has no option to mount an older session. The
BSDs are unable to do multi-session above 4 GiB. Solaris
and BSDs cannot properly represent in a mounted ISO 9660
files of size 4 GiB or larger.
Not to speak of the stability of the USB driver when
a drive gets powered off or unplugged.

So i stay with Linux despite some frustration.
(The CD TAO read-ahead bug is about 20 years old now.
systemd adds a new layer of interference without
solving the old problem of uncoordinated drivers.)

(End of rant zone)
---------------------------------------------------------


Have a nice day :)

Thomas

[Richardson, Eric J]

Hello Jörg,

Thank you for responding! I would be happy to use cdrtools for writing, if I could figure out how. I tried, Lord how I tried. Unfortunately, I am having less success using mkisofs and cdrecord to make a multisession DVD than I had with growisofs.

I read your howto here:
http://cdrtools.sourceforge.net/private/man/README/README.multi

Using this, I figured that I make the initial iso (raw) image with this command:

mkisofs -R -o /tmp/file.raw file1file1file1_REDHAT.txt file2file2file2_REDHAT.txt file3file3file3_REDHAT.txt

So far, so good. I write the file with:

cdrecord -v speed=2 dev=1,0,0 -multi /tmp/file.raw

So far, so good. Let's try to mount that baby:

mount /dev/sr0 /media/
mount: you must specify the filesystem type

Fine. Try it with the filesystem type:

mount -o ro -t iso9660 /dev/sr0 /media/
mount: no medium found on /dev/sr0

Okay, that's not the end of the world. I would like to be able to mount it, but what I REALLY want to do is write a second session. Let's try the msinfo to get the data for the second session:

cdrecord -msinfo dev=2,0,0
cdrecord: Warning: Cannot read drive buffer.
cdrecord: Warning: The DMA speed test has been skipped.
0,93952

Great! Let's try a mkisofs now:

mkisofs -R -C 0,93952 -M /dev/sr0 -o /tmp/file.raw file4file4file4_REDHAT.txt file5file5file5_REDHAT.txt file6file6file6_REDHAT.txt
Setting input-charset to 'UTF-8' from locale.
mkisofs: Input/output error. test unit ready: scsi sendcmd: no error
CDB: 00 00 00 00 00 00
status: 0x2 (CHECK CONDITION)
Sense Bytes: 70 00 02 00 00 00 00 0A 00 00 00 00 3A 00 00 00
Sense Key: 0x2 Not Ready, Segment 0
Sense Code: 0x3A Qual 0x00 (medium not present) Fru 0x0
Sense flags: Blk 0 (not valid)
cmd finished after 0.002s timeout 20s
mkisofs: Success. Unable to open previous session image '/dev/sr0'.

There's no file.raw, so that's an odd definition of "success." Let's try it with /dev/dvd:

mkisofs -R -C 0,93952 -M /dev/dvd -o /tmp/file.raw file4file4file4_REDHAT.txt file5file5file5_REDHAT.txt file6file6file6_REDHAT.txt
Setting input-charset to 'UTF-8' from locale.
mkisofs: Short read on old image

Fine. Let's try it with dev=2,0,0:

mkisofs -R -C 0,93952 -M dev=2,0,0 -o /tmp/file.raw file4file4file4_REDHAT.txt file5file5file5_REDHAT.txt file6file6file6_REDHAT.txt
Setting input-charset to 'UTF-8' from locale.
mkisofs: Invalid argument. Invalid bus or target specifier in 'dev=2,0,0'. Cannot open SCSI driver.
mkisofs: Invalid argument. Unable to open previous session image 'dev=2,0,0'.

Clearly that is not how I specify the device. I cannot write the second session, and am dead in the water. Just for the sake of completeness, I will reload the tray.

After ejecting and re-inserting the media, I can now mount it, but only by specifying the filesystem type. After trying several variations on writing a new rawfile, I got this:

mkisofs -R -C 0,93952 -M /dev/dvd -o /tmp/file.raw file4file4file4_REDHAT.txt file5file5file5_REDHAT.txt file6file6file6_REDHAT.txt
Setting input-charset to 'UTF-8' from locale.
ISO-9660 image includes checksum signature for correct inode numbers.
SUSP signatures version 1 found
Rock Ridge signatures version 1 found
Rock Ridge id 'RRIP_1991A'
Total translation table size: 0
Total rockridge attributes bytes: 821
Total directory bytes: 0
Path table size(bytes): 10
Max brk space used 0
178 extents written (0 MB)

Super! Let's write the new rawfile to the disk:

cdrecord -v speed=2 dev=2,0,0 -multi /tmp/file.raw
cdrecord: No write mode specified.
cdrecord: Assuming -tao mode.
cdrecord: Future versions of cdrecord may have different drive dependent defaults.
Cdrecord-ProDVD-ProBD-Clone 3.01a27 (x86_64-unknown-linux-gnu) Copyright (C) 1995-2015 Joerg Schilling
TOC Type: 3 = CD-ROM XA mode 2
scsidev: '2,0,0'
scsibus: 2 target: 0 lun: 0
Linux sg driver version: 3.5.34
Using libscg version 'schily-0.9'.
SCSI buffer size: 64512
atapi: 1
Device type : Removable CD-ROM
Version : 5
Response Format: 2
Capabilities :
Vendor_info : 'TSSTcorp'
Identifikation : 'CDDVDW TS-H653B '
Revision : 'SI01'
Device seems to be: Generic mmc2 DVD-R/DVD-RW/DVD-RAM.
Current: DVD-R sequential recording
Profile: DVD-R/DL sequential recording
Profile: DVD-R/DL layer jump recording
Profile: DVD+R/DL
Profile: DVD+R
Profile: DVD+RW
Profile: DVD-RW sequential recording
Profile: DVD-RW restricted overwrite
Profile: DVD-RAM
Profile: DVD-R sequential recording (current)
Profile: DVD-ROM
Profile: CD-RW
Profile: CD-R
Profile: CD-ROM
Profile: Removable Disk
Using generic SCSI-3/mmc-2 DVD-R/DVD-RW/DVD-RAM driver (mmc_dvd).
Driver flags : NO-CD DVD MMC-3 SWABAUDIO BURNFREE
Supported modes: PACKET SAO LAYER_JUMP
Drive buf size : 1376256 = 1344 KB
cdrecord: Warning: Cannot read drive buffer.
cdrecord: Warning: The DMA speed test has been skipped.
FIFO size : 4194304 = 4096 KB
Track 01: data 0 MB padsize: 244 KB
Total size: 0 MB = 300 sectors
Current Secsize: 2048
WARNING: Phys disk size 304 differs from rzone size 0! Prerecorded disk?
WARNING: Phys start: 196608 Phys end 196911
WARNING: Drive returns zero media size. Using media size from ADIP.
Blocks total: 304 Blocks current: -93648 Blocks remaining: -93948
cdrecord: Data does not fit on current disk.

No dice. I believe cdrecord must work at least as well as growisofs -- i.e., I should be able to write a second session to the disk, if only after reloading the tray -- so I must be doing something wrong. But I can't for the life of me figure out what.

Thanks again for your help! If I AM doing something wrong, I would love to know. If not, please enjoy Tigger, who needs a bath but does not want one:

-Eric J. Richardson

-----Original Message-----
From: Joerg Schilling [mailto:***@fokus.fraunhofer.de]
Sent: Friday, May 08, 2015 8:56 AM
To: cdrtools-***@lists.sourceforge.net; Richardson, Eric J; ***@other.debian.org
Subject: EXTERNAL: Re: Problem with growisofs -- cannot write multisession DVDs without ejecting and reloading tray

Post by Richardson, Eric J
http://fy.chalmers.se/~appro/linux/DVD+RW/
suggests I start here anyway.

Do you know that growisofs is unmaintained since 7 years?

Post by Richardson, Eric J
http://negativo17.org/cdrtools/
Linux 2.6.32-504.8.1.el6.x86_64
mkisofs 3.01a27 (x86_64-unknown-linux-gnu) Copyright (C) 1993-1997
Eric Youngdale (C) 1997-2015 Joerg Schilling
front-ending to mkisofs: mkisofs 3.01a27 (x86_64-unknown-linux-gnu)
Copyright (C) 1993-1997 Eric Youngdale (C) 1997-2015 Joerg Schilling
Cdrecord-ProDVD-ProBD-Clone 3.01a27 (x86_64-unknown-linux-gnu)
Copyright (C) 1995-2015 Joerg Schilling

If you have a recent cdrtools installed, why don't you use it for writing?

Unlike growisofs, cdrtools is actively maintained.

If you have problems with cdrtools, this can be fixed....

You would need to send a bug report - I am not aware of problems in the recent version.

Jörg
--
EMail:***@schily.net (home) Jörg Schilling D-13353 Berlin
***@fokus.fraunhofer.de (work) Blog: http://schily.blogspot.com/
URL: http://cdrecord.org/private/ http://sourceforge.net/projects/schilytools/files/'

[Richardson, Eric J]

It seems that you are using the wrong devices.....
You started with dev=1,0,0, why did you try to use a different device later on?

Post by Richardson, Eric J
cdrecord -v speed=2 dev=1,0,0 -multi /tmp/file.raw

But the later ones I copied directly from the screen. I am not really switching devices; I just got the machines confused when I typed the first command.

Given the fact that you did not report about errors from the first write process, I assume that you used the right device.

Yes, I use dev=2,0,0 for the initial cdrecord. I got this number from cdrecord -scanbus. Using this device does not generate any errors.

Given the fact that you could not mount the device, I assume that you used the wrong UNIX device name.

I use /dev/sr0 to mount the device. I cannot mount the drive, using /dev/sr0 OR /dev/dvd, after the first write without manually reloading the tray. After I reload the tray, /dev/sr0 mounts just fine. I cannot perform the second write at all, as I said. From reading the man page, I think I am supposed to use the UNIX device name with the -M in mkisofs, but mkisofs does not like /dev/sr0. It did attempt to write when I used /dev/dvd, which is a link to /dev/sr1, but I don't know enough about Linux device names to know why. As I said in my first email, the attempt to write was unsuccessful.

If there is only on CD-ROM type device on your machine, cdrecord will use the right one without a need to specify dev= - read the man pages....

Yes, I read that in the man pages, but there is a second CD-ROM device that confuses things. The KVM that this machine is on attaches a "bonus" device via USB, which for some reason shows up as a CD drive at 0,0,0. This is why I specify the dev.


-Eric J. Richardson

-----Original Message-----
From: Joerg Schilling [mailto:***@fokus.fraunhofer.de]
Sent: Tuesday, May 12, 2015 3:50 AM
To: Richardson, Eric J; ***@other.debian.org; cdrtools-***@lists.sourceforge.net
Subject: Re: EXTERNAL: Re: Problem with growisofs -- cannot write multisession DVDs without ejecting and reloading tray

Hello Jörg,
Thank you for responding! I would be happy to use cdrtools for writing, if I could figure out how. I tried, Lord how I tried. Unfortunately, I am having less success using mkisofs and cdrecord to make a multisession DVD than I had with growisofs.
http://cdrtools.sourceforge.net/private/man/README/README.multi
mkisofs -R -o /tmp/file.raw file1file1file1_REDHAT.txt
file2file2file2_REDHAT.txt file3file3file3_REDHAT.txt
cdrecord -v speed=2 dev=1,0,0 -multi /tmp/file.raw
mount /dev/sr0 /media/
mount: you must specify the filesystem type
mount -o ro -t iso9660 /dev/sr0 /media/
mount: no medium found on /dev/sr0
cdrecord -msinfo dev=2,0,0
cdrecord: Warning: Cannot read drive buffer.
cdrecord: Warning: The DMA speed test has been skipped.
0,93952
mkisofs -R -C 0,93952 -M /dev/sr0 -o /tmp/file.raw
file4file4file4_REDHAT.txt file5file5file5_REDHAT.txt file6file6file6_REDHAT.txt Setting input-charset to 'UTF-8' from locale.
mkisofs: Input/output error. test unit ready: scsi sendcmd: no error
CDB: 00 00 00 00 00 00
status: 0x2 (CHECK CONDITION)
Sense Bytes: 70 00 02 00 00 00 00 0A 00 00 00 00 3A 00 00 00 Sense
Key: 0x2 Not Ready, Segment 0 Sense Code: 0x3A Qual 0x00 (medium not
present) Fru 0x0

It seems that you are using the wrong devices.....

You started with dev=1,0,0, why did you try to use a different device later on?

What if the correct UNIX device name for SCSI dev=1,0,0 on your machine?

I recommend you to start with a

cdrecord -scanbus

If there is only on CD-ROM type device on your machine, cdrecord will use the right one without a need to specify dev= - read the man pages....

If you like to access the block device (e.g. four mounting), you need to know the UNIX device name, I hope that you know the right names for your machine.

Given the fact that you did not report about errors from the first write process, I assume that you used the right device. Given the fact that you could not mount the device, I assume that you used the wrong UNIX device name.

Jörg
--
EMail:***@schily.net (home) Jörg Schilling D-13353 Berlin
***@fokus.fraunhofer.de (work) Blog: http://schily.blogspot.com/
URL: http://cdrecord.org/private/ http://sourceforge.net/projects/schilytools/files/'

[Thomas Schmitt]

Hi,

Post by Thomas Schmitt
xorriso

"Chorizo"? "Shore-Isso"? "Zoar-Eyesoh"?

X/Open on Rock Ridge enhanced ISO 9660 = xorriso

I'm german and pronounce it like english "ksorreeso".
But actually one has just to know how to write its name. :))

But can it display the contents of the not-mounted filesystem without using
DVD+RW?

If you want it lengthy and complete:

xorriso -indev /dev/sr0 -find / -exec lsdl --

If you know what you look for

xorriso -indev /dev/sr0 -lsl /my/file/or/directory '/another/x*' --

Or if you like a dialog session:

xorriso -dialog on

then put in command lines like

-dev /dev/sr0
-lsl / --
-dus /my/directory --
-tell_media_space
-end

or manipulate the ISO for adding another session

-rm_r /do/not/want/this/tree/any/more --
-mv /old/path /newly/invented/path --
-map /tree/from/disk /tree/in/iso
-for_backup

cause writing of the new session by

-commit

or revoke the changes by

-rollback_end


Note that these are not options, which one can submit
in any sequence, but rather commands which get executed
in the sequence they are given. I.e. you first need
to read the metadata by -indev before you can inquire
them by -find.
Commands with a variable number of arguments get their
end marked by '--', so that more than one command can be
witten into one line. Line end is equivalent to '--',
though. You may as well end any command by '--'. Surplus
'--' get ignored. Command -list_delimiter can choose
another delimiter string instead of '--'.

man xorriso(1) has 4730 lines which hopefully explain
most of its properties. Users are advised to start
with the EXAMPLES section.

Yeah, we have been accepting a waste of 200MB on the first session as a fact
of life.

The 200 MB probably are due to a decision of the drive
which believes that the first session needs to be larger
than the few KB which you did put in. (I know of a 1 GB
minimum size for DVD-R DAO. But your run was Incremental,
rather than DAO.)

If the use case needs write-once media:
DVD+R waste only 4 MB per session.

Would the kernel developers take this particular problem more seriously if
more people complained about it?

The place to complain would be LKML (Linux Kernel Mailing List).
Be aware that the language there can be very direct (cough)
and that nobody there waited for a userlander who cannot
fix his kernel problems by own means.
(We userlanders better solve our problems were we live.)

Post by Thomas Schmitt
Solaris has no option to mount an older session.

That is curious to me, since as I said, the way I proved this wasn't a
"hardware problem" was by showing that it worked on Solaris 10.

OpenSolaris snv 134 always mounts the youngest session.
(There are traces in growisofs that Solaris once mounted
always the first session.)
Linux (by mount -o sbsector=) and FreeBSD (by mount -s) offer an
opportunity to mount any of the sessions if you know their start
block (e.g. from xorriso command -toc).

Solaris man mount(8) does not offer such an option.
I peeked into the OpenSolaris kernel and saw no means to send
down a start block parameter to the function which chooses
the superblock address for mounting.


Have a nice day :)

Thomas

[Thomas Schmitt]

Hi,

Post by Thomas Schmitt
OpenSolaris snv 134 always mounts the youngest session.

You'll have to forgive me, but I don't know what this means. Would that
mean that only the last files written can be seen, or all of them?

You see all files which you added (and did not delete later).

The capability to access older states is interesting with
incremental backups.

ISO 9660 multi-session works like this:

The new session adds a new superblock, a new complete directory
tree, and the content of data files which were newly added
or overwritten by the session.

The older superblocks and directory trees still exist on the
disc. They may point to older versions of files which got
replaced by other content in further sessions, and they may
contain files which were deleted from the directory tree
of the younger sessions.

Operating systems by default use the youngest superblock
and directory tree for mounting.

But as said, mounting older sessions imight be desirable with
incremental backups. E.g. if i want to mount the backup state
of three days ago, i put in my backup BD-R and do

xorriso -indev /dev/sr2 -toc

which tells me

TOC layout : Idx , sbsector , Size , Volume Id
ISO session : 1 , 0 , 1461973s , HOME_2015_01_05_130954
ISO session : 2 , 1462144 , 53613s , HOME_2015_01_06_114520
...
ISO session : 126 , 8364224 , 54847s , HOME_2015_05_10_113721
ISO session : 127 , 8419232 , 62170s , HOME_2015_05_11_120517
ISO session : 128 , 8481568 , 63170s , HOME_2015_05_12_135346
Media summary: 128 sessions, 8544896 data blocks, 16.3g data, 7177m free

If i then execute (on Linux)

mount -o sbsector=8364224 /dev/sr2 /mnt/iso

i get to see the backup state of may 10 2015, 11:37:21.

There is some convenience built in. The run

xorriso -mount_cmd /dev/sr2 volid '*_2015_05_10_*' /mnt/iso

on Linux makes this proposal of a mount command:

mount -t iso9660 -o nodev,noexec,nosuid,ro,sbsector=8364224 '/dev/sr2' '/mnt/iso'

On FreeBSD the proposal would rather look like
mount_cd9660 -o noexec,nosuid -s 8364224 '/dev/cd1' '/mnt/iso'

A privileged user may also do

xorriso -osirrox on -mount /dev/sr2 volid '*_2015_05_10_*' /mnt/iso

and have the proposed command executed directly by xorriso.
(One still has to umount manually, when done.)

My backup sessions got their volume ids with time stamp
by xorriso command

-volid HOME_"$(date '+%Y_%m_%d_%H%M%S')"

when the backups were made. (See man page example
"Incremental backup of a few directory trees".)

[Richardson, Eric J]

Hi Thomas,

As always, thank you for your helpful responses.

The new session adds a new superblock, a new complete directory tree, and the content of data files which were newly added or overwritten by the session.

Ohhhh that makes sense. I was thinking that the entire DVD had one superblock at the beginning, and that couldn't be right, because how would it get updated?

But as said, mounting older sessions imight be desirable with incremental backups. E.g. if i want to mount the backup state of three days ago,

I hadn't thought of that as a possible use. We always date our backups and log files in the filename, so if we want an older one we just go to the file with the correct date.

A couple more questions:

I am trying to figure out if I can close a DVD without writing a new file to it. I searched the man page and came up with:

xorriso -dev /dev/sr1 -close on --

This looks like a good command -- it doesn't spit out errors as such -- but it doesn't do anything. I can still append data to the medium, so it didn't close the disk. But, if I write a file, as in:

xorriso -dev /dev/sr1 -close on -add closeme.txt --

Then the medium gets closed, and I can no longer write to it. Is this the only way to close the disk? That is, do I have to write some file if I arbitrarily decide it's time to close the disk?

The number of sessions on DVD-R is restricted to 99, on DVD+R the limit is 153.

This is very helpful to know, when combined with the number of tracks I have written. I figured out that:

xorriso -dev /dev/sr1 -status short

will give me the status that a normal write prints out without having to write anything, which is useful. It tells me how many sessions are on the disk, and how much space has been used (including padding), and how much space is left. My question is, is there a way to get the number of session left for the medium? Short of manually subtracting the number of sessions on the disk from 99, that is.

Thanks, and have a great day,

-Eric J. Richardson

-----Original Message-----
From: Thomas Schmitt [mailto:***@gmx.net]
Sent: Wednesday, May 13, 2015 12:23 AM
To: ***@other.debian.org
Cc: Richardson, Eric J
Subject: EXTERNAL: Re: Problem with growisofs -- cannot write multisession DVDs without ejecting and reloading tray

Hi,

Post by Thomas Schmitt
OpenSolaris snv 134 always mounts the youngest session.

You'll have to forgive me, but I don't know what this means. Would
that mean that only the last files written can be seen, or all of them?

You see all files which you added (and did not delete later).

The capability to access older states is interesting with incremental backups.

ISO 9660 multi-session works like this:

The new session adds a new superblock, a new complete directory tree, and the content of data files which were newly added or overwritten by the session.

The older superblocks and directory trees still exist on the disc. They may point to older versions of files which got replaced by other content in further sessions, and they may contain files which were deleted from the directory tree of the younger sessions.

Operating systems by default use the youngest superblock and directory tree for mounting.

But as said, mounting older sessions imight be desirable with incremental backups. E.g. if i want to mount the backup state of three days ago, i put in my backup BD-R and do

xorriso -indev /dev/sr2 -toc

which tells me

TOC layout : Idx , sbsector , Size , Volume Id
ISO session : 1 , 0 , 1461973s , HOME_2015_01_05_130954
ISO session : 2 , 1462144 , 53613s , HOME_2015_01_06_114520
...
ISO session : 126 , 8364224 , 54847s , HOME_2015_05_10_113721
ISO session : 127 , 8419232 , 62170s , HOME_2015_05_11_120517
ISO session : 128 , 8481568 , 63170s , HOME_2015_05_12_135346
Media summary: 128 sessions, 8544896 data blocks, 16.3g data, 7177m free

If i then execute (on Linux)

mount -o sbsector=8364224 /dev/sr2 /mnt/iso

i get to see the backup state of may 10 2015, 11:37:21.

There is some convenience built in. The run

xorriso -mount_cmd /dev/sr2 volid '*_2015_05_10_*' /mnt/iso

on Linux makes this proposal of a mount command:

mount -t iso9660 -o nodev,noexec,nosuid,ro,sbsector=8364224 '/dev/sr2' '/mnt/iso'

On FreeBSD the proposal would rather look like
mount_cd9660 -o noexec,nosuid -s 8364224 '/dev/cd1' '/mnt/iso'

A privileged user may also do

xorriso -osirrox on -mount /dev/sr2 volid '*_2015_05_10_*' /mnt/iso

and have the proposed command executed directly by xorriso.
(One still has to umount manually, when done.)

My backup sessions got their volume ids with time stamp by xorriso command

-volid HOME_"$(date '+%Y_%m_%d_%H%M%S')"

when the backups were made. (See man page example "Incremental backup of a few directory trees".)

[Thomas Schmitt]

Hi,

Post by Richardson, Eric J

Post by Thomas Schmitt
The new session adds a new superblock,

I was thinking that the entire DVD had one
superblock at the beginning, and that couldn't be right, because how would
it get updated?

This is the situation with overwritable media:
DVD+RW, DVD-RAM, BD-RE, formatted DVD-RW, formatted CD-RW,
data files, Linux block devices.

The new session gets written like with sequential media
(CD-R, CD-RW, DVD-R, DVD+R, BD-R, unformatted DVD-RW)
but the superblock at block offset 0 gets overwritten to
lead the mounters to the youngest session.
xorriso by default creates the superblock of the first
session at offset 32 and a copy at offset 0. This way
the superblock at offset 32 survives the updates at
offset 0 when more sessions get burned.

Post by Richardson, Eric J
I am trying to figure out if I can close a DVD without writing a new file to
it.

Interesting use case. I don't think that my stuff can do
this. But i dimly remember that growisofs ...
man 1 growisofs, EXAMPLES:

"To finalize the multi-session DVD maintaining maximum compatibility:
growisofs -M /dev/dvd=/dev/zero
"
(I never tried this.)

Post by Richardson, Eric J
xorriso -dev /dev/sr1 -status short

Command -status will tell you the current settings of various
xorriso commands, but nearly nothing about the medium state.

The info about the number of sessions is put out on stderr
after a drive was aquired by -dev, -indev, or -outdev.

$ xorriso -outdev /dev/sr2 2>&1 | grep '^Media summary:'
Media summary: 129 sessions, 8597504 data blocks, 16.4g data, 7074m free

The command -toc puts out the line "Media summary:", too.
Its output goes to stdout. Its line "Media blocks :" gives
exact sizes counted in units of 2048 bytes.

$ toc=$(xorriso -outdev /dev/sr2 -toc 2>/dev/null)
$ echo "$toc" | grep '^Media blocks :'
Media blocks : 8597504 readable , 3621888 writable , 12219392 overall
$ echo "$toc" | grep '^Media summary:'
Media summary: 129 sessions, 8597504 data blocks, 16.4g data, 7074m free

Post by Richardson, Eric J
is there a way to get the number of session
left for the medium? Short of manually subtracting the number of sessions
on the disk from 99, that is.

Not yet. The numbers 99 and 153 are theoretical values.
The real number of remaining sessions depends on the size of
those sessions and on the gaps between sessions.

With BD-R there is no limit announced in the MMC specs.
My oldest BD burner can put more than 300 on the medium
before it fails quite miserably. My younger ones throw
error after about 120 to 140 sessions. (I am awaiting the
refusal of my current backup BD-R every day.)
For professional purposes i would impose a limit of 100
sessions and then just begin with a new medium.


Have a nice day :)

Thomas

[Richardson, Eric J]

Hi Thomas,

Thank you for your responses. It is looking like we will go with xorriso, at least we will if I have anything to say about it. One last question, and then I will stop clogging up the list:

Can xorriso toggle the drive tray? That is, is there a xorriso equivalent of eject -T? Not that it matters: I can just use eject -T (on drives where this is an option). I was only curious, since the status doesn't seem to report whether the drive is open or closed.

Thank you for all your help,

-Eric J. Richardson

-----Original Message-----
From: Thomas Schmitt [mailto:***@gmx.net]
Sent: Thursday, May 14, 2015 12:47 AM
To: ***@other.debian.org
Cc: Richardson, Eric J
Subject: EXTERNAL: Re: Problem with growisofs -- cannot write multisession DVDs without ejecting and reloading tray

Hi,

Post by Richardson, Eric J

Post by Thomas Schmitt
The new session adds a new superblock,

I was thinking that the entire DVD had one superblock at the
beginning, and that couldn't be right, because how would it get
updated?

This is the situation with overwritable media:
DVD+RW, DVD-RAM, BD-RE, formatted DVD-RW, formatted CD-RW,
data files, Linux block devices.

The new session gets written like with sequential media (CD-R, CD-RW, DVD-R, DVD+R, BD-R, unformatted DVD-RW) but the superblock at block offset 0 gets overwritten to lead the mounters to the youngest session.
xorriso by default creates the superblock of the first session at offset 32 and a copy at offset 0. This way the superblock at offset 32 survives the updates at offset 0 when more sessions get burned.

Post by Richardson, Eric J
I am trying to figure out if I can close a DVD without writing a new
file to it.

Interesting use case. I don't think that my stuff can do this. But i dimly remember that growisofs ...
man 1 growisofs, EXAMPLES:

"To finalize the multi-session DVD maintaining maximum compatibility:
growisofs -M /dev/dvd=/dev/zero
"
(I never tried this.)

Post by Richardson, Eric J
xorriso -dev /dev/sr1 -status short

Command -status will tell you the current settings of various xorriso commands, but nearly nothing about the medium state.

The info about the number of sessions is put out on stderr after a drive was aquired by -dev, -indev, or -outdev.

$ xorriso -outdev /dev/sr2 2>&1 | grep '^Media summary:'
Media summary: 129 sessions, 8597504 data blocks, 16.4g data, 7074m free

The command -toc puts out the line "Media summary:", too.
Its output goes to stdout. Its line "Media blocks :" gives exact sizes counted in units of 2048 bytes.

$ toc=$(xorriso -outdev /dev/sr2 -toc 2>/dev/null)
$ echo "$toc" | grep '^Media blocks :'
Media blocks : 8597504 readable , 3621888 writable , 12219392 overall
$ echo "$toc" | grep '^Media summary:'
Media summary: 129 sessions, 8597504 data blocks, 16.4g data, 7074m free

Post by Richardson, Eric J
is there a way to get the number of session left for the medium?
Short of manually subtracting the number of sessions on the disk from
99, that is.

Not yet. The numbers 99 and 153 are theoretical values.
The real number of remaining sessions depends on the size of those sessions and on the gaps between sessions.

With BD-R there is no limit announced in the MMC specs.
My oldest BD burner can put more than 300 on the medium before it fails quite miserably. My younger ones throw error after about 120 to 140 sessions. (I am awaiting the refusal of my current backup BD-R every day.) For professional purposes i would impose a limit of 100 sessions and then just begin with a new medium.


Have a nice day :)

Thomas

[Thomas Schmitt]

Hi,

Post by Richardson, Eric J
Can xorriso toggle the drive tray? That is, is there a xorriso equivalent
of eject -T?

It tries to load the tray when it aquires a drive.
(SCSI command START/STOP UNIT with Start bit and Load/Eject bit set.)

Whether the drive obeys depends on having a drive tray motor.
If eject -T works, then
xorriso ... -dev /dev/sr0 ...
is supposed to work, too.

Post by Richardson, Eric J
I was only curious, since the status doesn't seem to
report whether the drive is open or closed.

If
-status -indev
reports a drive address, then there is an ISO filesystem
loaded or a blank medium aquired. Thus the tray must be in
and either -dev or -indev was used to aquire the drive.

With -outdev it should be possible to have a drive aquired
which has left its tray open. (I have no laptop drive which
would have no tray motor. But empty drives stay aquired with
-outdev.)

You can do your first session on blank medium by -dev.
My example in a previous mail uses -outdev to assert that
the medium is blank. (xorriso refuses to add a session to
a non-blank medium from which it did not load ISO meta data.)
This list is really not clogged by on-topic conversations.
Be invited to ask if you got more questions.


Have a nice day :)

Thomas