Tree - rpms/dvd+rw-tools - CentOS Git server

rpms / dvd+rw-tools

Blame SOURCES/index.html

Blob History Raw

<HTML>

e0037e

<HEAD>

e0037e

<BASE HREF="http://fy.chalmers.se/~appro/linux/DVD+RW/">

e0037e

<TITLE>Blu-ray Disc/DVD+RW/+R/-R[W] for Linux</TITLE>

e0037e

			       dvd+rw, dvd+r, dvdplusrw, dvd-rw, dvd-r, dvd-ram,

e0037e

			       dvd+r double layer, dvd+r dl, dvd-r dl,

e0037e

			       blu-ray, blu-ray disc, bd, bd-r, bd-re,

e0037e

			       linux, netbsd, openbsd, solaris, freebsd, hp-ux, irix, unix,

e0037e

			       mac os x, windows, mingw, win32, win64,

e0037e

			       hp, ricoh, philips, sony, nec, plextor, benq,

e0037e

			       optorite, lite-on, pioneer, lg, panasonic, matshita,

e0037e

			       multisession, growisofs">

e0037e

				  user-land utilities and optional Linux

e0037e

				  kernel patch">

e0037e

<META HTTP-EQUIV="Content-Type" CONTENT="text/html; charset=iso-8859-1">

e0037e

<LINK REL="icon" HREF="dvdplusrw.ico" TYPE="image/x-icon">

e0037e

<LINK REL="shortcut icon" HREF="dvdplusrw.ico" TYPE="image/x-icon">

e0037e

</HEAD>

e0037e

      LINK="#0000D0" VLINK="#502090" ALINK="#FF0000">

e0037e

Blu-ray Disc/

e0037e

HREF="http://www.dvdrw.com/">DVD+RW/+R/

e0037e

HREF="-RW/">-R[W] for Linux

e0037e

by <appro@fy.chalmers.se>,

e0037e

September 2006

e0037e

HREF="http://www.ioss.jp/sohodiy/vol02-part01.html">

e0037e

SRC="japanese.gif" WIDTH=48 HEIGHT=19 BORDER=0 ALT="Japanese">

e0037e

Q.	What is this page (not) about?

e0037e

A.<SUP> </SUP>

e0037e

	Maybe to your disappointment it is not about

e0037e

	video<SUP>(*)</SUP>. The scope of this page is primarily

e0037e

	computer storage applications of Blu-ray Disc and

e0037e

	DVD±RW/±R, things like backup, archiving, data

e0037e

	exchange... The downloadable files are an optional

e0037e

	HREF="linux-2.4.patch">Linux 2.4 kernel DVD+RW patch and a

e0037e

	couple of user-land utilities dubbed as <NOBR>

e0037e

	HREF="tools/?M=D">dvd+rw-tools</NOBR>.

e0037e

	<FONT SIZE="-1"><SUP>(*)</SUP></FONT>

e0037e

	<FONT SIZE="-1">Though it doesn't mean that you can't burn

e0037e

	DVD-Video discs with dvd+rw-tools. [Unlike Video-CD] DVD-Video

e0037e

	is "molded" in an ordinary data file system and

e0037e

	therefore no explicit support by the burning program is

e0037e

	actually required. In other words it is the DVD-Video

e0037e

	content preparation which is beyond the scope of this

e0037e

	page.</FONT>

e0037e

Q.	Kernel patch? This sounds too complicated

e0037e

	already! Can't I just use [vanilla] cdrecord?

e0037e

A.	It should be explicitly noted that the user-land

e0037e

	utilities, dvd+rw-tools, do suffice for BD/DVD recording

e0037e

	without explicit kernel support. So if they

e0037e

	HREF="#tutorial">fulfill your requirements, then

e0037e

	patching the kernel is by all means optional. As

e0037e

	for [vanilla] cdrecord, non-CD recording strategies are

e0037e

	somewhat different, so it simply doesn't work (nor does

e0037e

	dvdrecord with media other than DVD-R[W], despite what

e0037e

	HREF="http://www.redhat.com/docs/manuals/linux/RHL-7.3-Manual/release-notes/x86/">RedHat

e0037e

	7.3 Release Notes say). On additional note Linux kernel

e0037e

	version 2.6>=10 is equipped with

e0037e

	HREF="http://web.telia.com/~u89404340/packet.html">packet

e0037e

	writing driver which supports even DVD rewritable media,

e0037e

	but I haven't tested it myself, so don't ask:-)

e0037e

Q.	What is the kernel patch good for then?

e0037e

A.	DVD+RW (but not DVD+R nor any DVD-dash) is a true random

e0037e

	write access media and therefore is suitable for housing of an

e0037e

	arbitrary file system, e.g. udf, vfat, ext2, etc. This,

e0037e

	and this alone, qualifies DVD+RW support for kernel

e0037e

	implementation. However, I have to recommend to

e0037e

	deploy it with caution, see tutorial

e0037e

	for further details. Also note that not all OEMs seem to live

e0037e

	up to the promise of true random write access. As for the

e0037e

	moment of this writing apparenly only 2nd generation

e0037e

	Ricoh-based units (see

e0037e

	HREF="http://www.dvdplusrw.org/">dvdplusrw.org for

e0037e

	generation listings) equipped with later firmware can sustain

e0037e

	I/O fragmentation (see Technical Ramblings below for further

e0037e

	details) and perform reliably.

e0037e

Q.	What are the dvd+rw-tools for?

e0037e

A.	As implied/already mentioned - to master the

e0037e

	HREF="Blu-ray/">Blu-ray Disc and DVD media, both +RW/+R and

e0037e

	-R[W]. I could simply refer to the

e0037e

	tutorial below, but figured that couple of words about the

e0037e

	[original] design ideas behind growisofs, the principal

e0037e

	burning utility, wouldn't harm. Even though a modified

e0037e

	kernel can let you put for example an ext2 file system on

e0037e

	DVD+RW, it's probably not very practical, because you most

e0037e

	likely want to access the data on an arbitrary computer.

e0037e

	Or in other words you most likely want ISO9660. The trouble is

e0037e

	that you might as well want to add data now and then.

e0037e

	And what options do you have in the lack of multiple sessions

e0037e

	(no, DVD+RW has no notion of multiple sessions)? Complete

e0037e

	re-mastering which takes more and more time as data set grows?

e0037e

	Well, yes, unless you employ growisofs! Growisofs

e0037e

	provides the way to both lay down and grow an ISO9660

e0037e

	file system on (as well as to burn an arbitrary pre-mastered

e0037e

	image to) all supported optical media.

e0037e

Q.	But if they support  both + and - recording

e0037e

	strategies, why are they called dvd+rw-tools?

e0037e

A.	For historical/nostalgical reasons, as originally they did

e0037e

	support exclusively DVD+plus. On the other hand now, when the

e0037e

	vast majority of DVD burners that are being introduced to the

e0037e

	market today are DVD+capable, the name most likely refers to

e0037e

	your unit in either case. And you can always consider the plus

e0037e

	in the name as notion of a unique quality, such as

e0037e

	"seamless" multisessioning, not as reference to some

e0037e

	particular format:-)

e0037e

Q.	Do I still need

e0037e

	HREF="http://cdrecord.berlios.de/old/private/cdrecord.html">cdrtools?

e0037e

A.	Yes. It should be explicitly noted that growisofs is a

e0037e

	front-end to mkisofs, i.e. invokes mkisofs to perform the

e0037e

	actual ISO9660 file system layout. Secondly, the DVD burners

e0037e

	available on the market can burn even CD-R[W] media and

e0037e

	cdrecord is the tool for this job [and this job only].

e0037e

Q.	There are dual-format DVD+RW/-RW units

e0037e

	available on the market, e.g. SONY DRU500. Can I use

e0037e

	dvd+rw-tools with it/them?

e0037e

A.	If the question is if you can use dvd+rw-tools to master the

e0037e

	DVD+RW/+R media in a ±RW drive, then the answer always

e0037e

	was "definitely yes." If the question really is if

e0037e

	you can use dvd+rw-tools to burn even DVD-R[W] media,

e0037e

	then I have the pleasure to inform you that as of version 5.0

e0037e

	dvd+rw-tools provide experimental support even for

e0037e

	recording of DVD-R[W] media and refer you to a

e0037e

	dedicated page for further details.

e0037e

-->

e0037e

Q.	Does it work with my recorder unit?

e0037e

A.	If your unit is

e0037e

	HREF="http://www.t10.org/drafts.htm#mmc3">MMC compliant,

e0037e

	then the answer is "most likely it

e0037e

	just does." Well, as the probability of your unit being

e0037e

	non-MMC compliant is virtually zero, the answer in practice is

e0037e

	unconditionally "most likely."

e0037e

	The [core] tools were reported to work with a wide range of

e0037e

	drives, including [but not limited to] <NOBR>HP

e0037e

	dvd[12345]x0i,</NOBR> <NOBR>Ricoh MP512x,</NOBR> <NOBR>Philips

e0037e

	DVDRW[248]xx,</NOBR> <NOBR>SONY DRU-[157]x0,</NOBR> <NOBR>NEC

e0037e

	ND-[1234]xx0,</NOBR> <NOBR>TDK indiDVD 4x0N,</NOBR>

e0037e

	<NOBR>Plextor PX-[57]xx,</NOBR> <NOBR>Benq DW[48]00A,</NOBR>

e0037e

	<NOBR>OptoRite DD0[24]0x,</NOBR> <NOBR>Lite-On

e0037e

	LDW-[4816]xxS,</NOBR> as well as nonplus

e0037e

	units such as <NOBR>Pioneer DVR-x0[45679],</NOBR> <NOBR>LG

e0037e

	GxA-40[248]x,</NOBR> <NOBR>Toshiba SD-R[56]112,</NOBR>

e0037e

	<NOBR>Panasonic UJ-811</NOBR>, <NOBR>LF-D[35]1x,</NOBR> and not

e0037e

	the least all-mighty

e0037e

	<NOBR>SW-5582...</NOBR>

e0037e

Q.	Is there a GUI front-end available for

e0037e

	dvd+rw-tools?

e0037e

A.	K3b, version 0.10

e0037e

	and later, and

e0037e

	HREF="http://ftp.gnome.org/pub/GNOME/sources/nautilus-cd-burner/">nautilus-cd-burner,

e0037e

	version 0.5.1 and later, are both hiding growisofs behind their

e0037e

	pretty buttons and menus:-) Keep in mind that those are not

e0037e

	directly related to <NOBR>dvd+rw-tools</NOBR> development

e0037e

	effort and GUI users should turn elsewhere for end-user

e0037e

	support. Oh! dvd+rw-tools 5.10.x is a minimum requirement for

e0037e

	GUI frontends...

e0037e

Q.	I don't run Linux. What are my options?

e0037e

A.	Version 5.4 adds support for

e0037e

	HREF="http://www.mosha.net/05-dvdrw/dvdrw.shtml">OpenBSD/NetBSD.

e0037e

	Version 5.6 adds support for Solaris 2.x

e0037e

	SIZE=-1>[commercial licensing

e0037e

	terms for distribution on Solaris are to be settled with

e0037e

	HREF="http://www.inserve.se/">Inserve Technology]</FONT>.

e0037e

	Version 5.8 features

e0037e

	HREF="http://www.freebsd.org/doc/en_US.ISO8859-1/books/handbook/creating-dvds.html">FreeBSD

e0037e

	port contributed by Matthew Dillon, FreeBSD Development Team

e0037e

	alumnus. <NOBR>Hewlett-Packard</NOBR> Company has donated

e0037e

	<NOBR>HP-UX 11</NOBR> support for

e0037e

	5.14<SUP>(*)</SUP>. IRIX 6.x support appears in

e0037e

	5.19, Win32 one - in 6.0,

e0037e

	while <NOBR>Mac OS X</NOBR> - in 7.0...

e0037e

¡

e0037e

	Common usage tip!<SUP> </SUP>Whenever

e0037e

	separately available [and unless stated otherwise], do use

e0037e

	character-type device entry with <NOBR>dvd+rw-tools,</NOBR>

e0037e

	e.g. OpenBSD/NetBSD users should stick to <TT>/dev/

e0037e

	COLOR="red">r</FONT>cdXc</TT>.

e0037e

	<FONT SIZE="-1">FreeBSD tip! If you have an IDE unit,

e0037e

	HREF="http://www.cuivre.fr.eu.org/~thomas/atapicam/">atapicam

e0037e

	is your mantra! Secondly, if you have <TT>devfs</TT> mounted,

e0037e

	you might have to mount

e0037e

	<TT>fdescfs</TT> as well.</FONT> -->

e0037e

	<FONT SIZE="-1"><SUP>(*)</SUP></FONT>

e0037e

	<FONT SIZE="-1">As of 5.14 HP-UX support was classified as

e0037e

	"initial." Version 5.18 in turn is the one which has

e0037e

	undergone HP quality assurance testing

e0037e

	and is delivered on HP

e0037e

	software depot.</FONT>

e0037e

Foreword

e0037e

As of May 2003 I've decided to advise users to

e0037e

turn to <

e0037e

HREF="mailto:cdwrite@other.debian.org">cdwrite@other.debian.org>

e0037e

on support matters. It's an open list, meaning that you don't have

e0037e

to be subscribed to post

e0037e

a problem report. List archives can be found at both

e0037e

HREF="http://lists.debian.org/cdwrite/">subscribe page and

e0037e

HREF="http://www.mail-archive.com/cdwrite%40other.debian.org/">mail-archive.com.

e0037e

When submitting report, provide versioning information, exact

e0037e

command line, exact output generated by the program and

e0037e

complement it with <NOBR>dvd+rw-mediainfo</NOBR> output for

e0037e

resulting recording. Do check couple of last

e0037e

HREF="http://lists.debian.org/cdwrite/">archived months, as the

e0037e

issue might have been  discussed recently. If you've chosen to

e0037e

contact me personally and haven't heard back within a week or so, then

e0037e

you most likely overlooked something on this page. Please read it more

e0037e

attentively...

e0037e

Special thanks for hardware donations [in

e0037e

chronological order]:

e0037e

ALT="Inserve Technology" BORDER=0>

e0037e

ALT="HP" BORDER=0>

e0037e

ALT="LinuxFund" BORDER=0>

e0037e

SRC="commtech.gif" ALT="comm*tech" BORDER=0>

e0037e

Tutorial

e0037e


If your burner unit is managed by some

e0037e

<NOBR>Linux<SUP>(*)</SUP></NOBR> removable media

e0037e

automounting/autoplaying facility, such as autofs, supermount,

e0037e

subfs/submount, magicdev, autorun or similar, take it out of its

e0037e

control! I can't help you with the latter, check your system

e0037e

documentation (such as google perhaps:-) for specific instructions.

e0037e

<FONT COLOR="brown">Failure to take your unit out of

e0037e

<NOBR>Linux<SUP>(*)</SUP></NOBR> automounting/autoplaying facility

e0037e

control can result in busted recording, a coaster!</FONT> At the

e0037e

very least you have to make sure your unit is not automounted during

e0037e

recordings.

e0037e

exclusive use," but it doesn't. Therefore the trouble... --->

e0037e

<FONT SIZE="-1"><SUP>(*)</SUP></FONT>

e0037e

<FONT SIZE="-1">dvd+rw-tools support Solaris volume manager and

e0037e

IRIX mediad in more gracious manner and it's safe to leave recorder

e0037e

under their control.</FONT>

e0037e


Remember to consult

e0037e

HREF="hcn.html">Hardware Compatibility Notes for possible

e0037e

caveats or vendor-specific instructions for your unit. Well, such

e0037e

reminder belongs at the end of tutorial, but I consider it important

e0037e

enough to bring it up already here:-)

e0037e


If you have an IDE unit and run 2.4.x

e0037e

kernel, you most likely want to "route" it through ide-scsi

e0037e

emulation layer by either:

e0037e

passing "<TT>hd<FONT COLOR="red">X</FONT>=ide-scsi</TT>"

e0037e

argument to kernel;

e0037e

appending following lines to your /etc/modules.conf:

e0037e

options ide-cd ignore=hd<FONT COLOR="red">X</FONT>

e0037e

pre-install sg modprobe ide-scsi

e0037e

pre-install sr_mod modprobe ide-scsi

e0037e

pre-install ide-scsi modprobe ide-cd

e0037e

Keep in mind that once hd<FONT COLOR="red">X</FONT>

e0037e

is routed through ide-scsi, you can no longer refer to <TT>/dev/hd

e0037e

COLOR="red">X</FONT></TT><SUP>(*)</SUP>, but to corresponding

e0037e

<TT>/dev/scd<FONT COLOR="red">N</FONT></TT> only.

e0037e

<FONT SIZE="-1"><SUP>(*)</SUP></FONT>

e0037e

<FONT SIZE="-1">well, except as in <TT>hdparm -d [0|1] /dev/hd

e0037e

COLOR="red">X</FONT></TT>. As for DMA settings. Several users of

e0037e

NEC[-based] units have reported that their systems crash during DVD

e0037e

recording. The problem appears to be related to DMA settings, at least

e0037e

switching it off reportedly helps. The problem appears to be specific to

e0037e

some IDE chipsets...</FONT>

e0037e


If you have an external unit, just get

e0037e

it working as CD-ROM first. I myself have no personal experience

e0037e

whatsoever with USB or

e0037e

HREF="http://www.linux1394.org/">IEEE1394/Firewire optical storage

e0037e

devices and have to direct you elsewhere for specific instructions. I

e0037e

however am confident that if you manage to get your drive working

e0037e

reliably as <NOBR>CD-ROM</NOBR> and <NOBR>CD-R[W]</NOBR>

e0037e

burner, then you won't have any troubles with dvd+rw-tools either. USB

e0037e

connected drives were reported to be working fine since eternity.

e0037e

Firewire connected drives in turn were reported to fail miserably under

e0037e

2.4.18. The failure didn't seem to be DVD recording related as it

e0037e

reportedly failed burning even CD-R media. Firewire support was

e0037e

substantially revamped in 2.4.19, and dvd+rw-tools were reported to

e0037e

work with this and later kernels.

e0037e


If you're running 2.4.19 or .20, consider

e0037e

applying this drivers/scsi/sg.c patch.

e0037e

The bug is fixed in .21. I write "consider" and not

e0037e

"do" for the following reasons:

e0037e

dvd+rw-tools are not affected by this bug (as they don't use SG_IO

e0037e

interface), cdrecord [potentially] is;

e0037e

I however haven't actually experienced the problem with cdrecord

e0037e

(maybe yet, kernel could have managed to keep buffers neatly aligned

e0037e

while talking to cdrecord those times I tried), it was VMware that has

e0037e

failed miserably on me;

e0037e

As of version 5.6 dvd+rw-tools add support for SG_IO

e0037e

pass-through or in other words support for Linux 2>=5[.43],

e0037e

where "generic" SCSI interface can be bypassed by issuing

e0037e

SG_IO ioctl directly against block device, such as <TT>/dev/hd

e0037e

COLOR="red">X</FONT></TT>. I wish it worked without need for

e0037e

HREF="http://marc.theaimsgroup.com/?t=105410790500005&r=1&w=2">interim

e0037e

patches #1 and

e0037e

HREF="ide-cd-2.5.69.+patch">#2, (the latter is relative to

e0037e

2.5.69-75, the 1st problem is addressed in .71, 2nd one - .75-bk3 in

e0037e

HREF="http://marc.theaimsgroup.com/?l=linux-kernel&m=105787192005635&w=2">last

e0037e

minute" prior first 2.6 cut. As for 2.6 in more general sense.

e0037e

As you can imagine this new interface renders ide-scsi layer

e0037e

superfluous and "the[ir] official plan™" is to scrap

e0037e

it. I'm not really fond of the idea, but not for /dev/sg* account. I

e0037e

mean I [personally] would prefer to keep ide-scsi and use SG_IO

e0037e

pass-through with <TT>/dev/scdN</TT>, rather than with

e0037e

<TT>/dev/hdX</TT>:-)

e0037e

If you have to make dvd+rw-tools work under Linux

e0037e

kernel 2.6.8, then upgrade the tool-chain to 5.21.x or later and

e0037e

manually reward the installed binaries with set-root-uid flag. But the

e0037e

"supported" recommendation is to just stay away from this

e0037e

particular kernel version. As for 2.6>8, dvd+rw-tools 5.21.x is

e0037e

requirement. Oh! dvd+rw-booktype utility would require set-root-uid

e0037e

privilege then. Given its semi-official status and the fact that this

e0037e

utility works only with limited number of units, installation procedure

e0037e

abstains from installing dvd+rw-booktype set-root-uid, leaving

e0037e

this security sensitive choice to the end-user.

e0037e


Download, unpack and compile the

e0037e

HREF="tools/?M=D">the tool-chain. To build the thing do pick the

e0037e

.tar.gz archive, which contains Makefile as well as .spec file. You

e0037e

will need both C and C++ compilers installed. Separate

e0037e

source code files found in the download catalog

e0037e

are provided mainly for on-line reference purposes (such as

e0037e

HREF="tools/growisofs.c">revision history:-).

e0037e

If your Linux kernel supports multiple ABIs (e.g.

e0037e

Linux-sparc64 can run even 32-bit Linux-sparc applications, as well as

e0037e

Linux-x86_64 can execute legacy 32-bit i386 binaries), make sure you

e0037e

compile for native 64-bit ABI (which can normally be done with

e0037e

'<TT>make TARGET_ARCH=-m64</TT>'). The problem here is that 64-bit

e0037e

kernel has to explicitly convert ioctl structures passed by 32-bit

e0037e

applications and apparently it does really lousy job when it comes to

e0037e

CDROM_SEND_PACKET ioctl deployed by dvd+rw-tools.

e0037e


As new media products and brands are being

e0037e

introduced to the market all the time, it apparently pays off to

e0037e

periodically check for firmware updates. For elder units

e0037e

firmware update might even be an absolute requirement for using

e0037e

new media. Special note for HP users. HP no longer posts firmware

e0037e

updates on a web-page. Instead they let some Windows auto-update gizmo

e0037e

to pick firmware updates among <NOBR><TT>dvd[1-6]00*.exe</TT></NOBR>

e0037e

files in

e0037e

HREF="ftp://ftp.hp.com/pub/information_storage/software/">their FTP

e0037e

directory, so that readers of this page tend to miss them...

e0037e


Formatting the BD and DVD+RW media.

e0037e

Virgin BD and DVD+RW media needs to be initally formatted prior usage.

e0037e

Once again, only virgin BD and DVD+RW media needs to be

e0037e

formatted. As of version 5.10 growisofs detects blanks and applies

e0037e

initial formatting procedure automatically. Otherwise same effect can

e0037e

be achieved by passing the device name, e.g. <TT>/dev/scd0</TT>, as an

e0037e

argument to dvd+rw-format. Well,

e0037e

in BD case it does offer more flexibility than

e0037e

growisofs. To make formatting process reasonably fast, less than 1

e0037e

minute, the media gets formatted only partially, as you can notice by

e0037e

observing progress indicator displayed by dvd+rw-format. The final

e0037e

indicator value varies from firmware to firmware, values as low as 1.6%

e0037e

were observed. But it does not mean that you can only write that

e0037e

little. The unit keeps formatting transparently, as you add more

e0037e

data. Oh! Do keep in mind that DVD capacity of 4.7GB is expressed in

e0037e

salesman's GB, i.e. 1000<SUP>3</SUP> and not 1024<SUP>3</SUP>. And

e0037e

so is one of BD.

e0037e

It was observed that excessive reformats can render

e0037e

DVD+RW media unusable already after 10-20 reformats. It appears to be a

e0037e

firmware deficiency, not some common media defect [at least it was

e0037e

perfectly possible to salvage the media in a unit of different brand],

e0037e

but I don't recommend [enforced] reformat in either case.

e0037e

Note that re-formatting procedure does not

e0037e

substitute for blanking. If you want to nullify the media, e.g. for

e0037e

privacy reasons, do it explicitly with '<TT>growisofs <NOBR>-Z</NOBR>

e0037e

/dev/scd<FONT COLOR="red">N</FONT>=/dev/zero</TT>'. Otherwise just

e0037e

write over previous recording as it simply wasn't there, no

e0037e

re-formatting is required.

e0037e

DVD+R media does not require any formatting

e0037e

procedure applied and is ready to use out-of-the-box. Apparently, a

e0037e

reminder that 1st generation units (Ricoh MP5120A and derivatives)

e0037e

are not capable of burning DVD+R is needed.--->

e0037e


Burning with

e0037e

HREF="tools/growisofs.c">growisofs. There is hardly a need for

e0037e

manual for growisofs. In a nutshell growisofs just passes all command

e0037e

line arguments to mkisofs and dumps its output directly onto the media.

e0037e

The first part means that you basically can [well, should]

e0037e

consult mkisofs manual page and

e0037e

accompanying reference documentation (including multisession related

e0037e

section[s]) and the second part means that you shouldn't expect an

e0037e

ISO-image on the standard output (nor make sure you have enough free

e0037e

temporary storage<TT>:-)</TT>. Differences from mkisofs command line

e0037e

are:

e0037e

you may not use -o option;

e0037e

you don't have to specify -C option, growisofs will construct one

e0037e

for you;

e0037e

there is internal -Z option for initial session recording, this

e0037e

substitutes for originally suggested 'mkisofs | dd of=/dev/scd0';

e0037e

Otherwise everything that applies to

e0037e

[multisession] mastering with mkisofs applies to growisofs as well. For

e0037e

example just like with mkisofs you should make a note on which options

e0037e

you used to master the initial "session" with and stick to

e0037e

them, e.g.:

e0037e

growisofs -Z /dev/scd0 <FONT COLOR="red">-R -J</FONT> /some/files

e0037e

growisofs -M /dev/scd0 <FONT COLOR="red">-R -J</FONT> /more/files

e0037e

Oh! Do make sure you have at least mkisofs

e0037e

COLOR="red">1.14</FONT> on your $PATH (mkisofs 1.14 is part of cdrtools

e0037e

1.10). If you consider passing <TT>/same/files</TT> as argument, or in

e0037e

other words consider deploying growisofs for incremental

e0037e

multisession backups, then you shall find

e0037e

HREF="mkisofs-2.01a16-root.diff">this '-old-root' extension to

e0037e

mkisofs <FONT COLOR="red">2

e0037e

HREF="mkisofs-2.0-root.diff">.0-2.01</FONT> simply indispensable.

e0037e

The idea and implementation by

e0037e

HREF="http://home.pages.de/~ohly/#mkisofs-root">Patrick Ohly is to

e0037e

"graft" recording sessions as separate directories. Each

e0037e

backup increment/directory is ment to contain both updated files and

e0037e

references to previously backed up ones, which facilitates

e0037e

comparison between increments as well as fine-graded restore.

e0037e

Number of users asked about opposite to

e0037e

multisessioning: multivolume support. Being essentially a recording

e0037e

program growisofs does not support multiple volumes by itself. There're

e0037e

couple of front-ends I can recommend that arrange for this:

e0037e

HREF="http://scdbackup.sourceforge.net/main_eng.html">scdbackup and

e0037e

shunt. But back to

e0037e

growisofs...

e0037e

In addition to intuitive -Z interpretation,

e0037e

growisofs [version 3.3 and later] recognizes special form of -Z command

e0037e

line option which permits burning of arbitrary pre-mastered images. The

e0037e

"magic" command is:

e0037e

growisofs -Z /dev/scd0<FONT COLOR="red">=</FONT>image.iso

e0037e

where <TT>image.iso</TT> represents an arbitrary

e0037e

object in the file system, such as file, named pipe or device

e0037e

entry. No, nothing is "growing" here and command name is

e0037e

counter-intuitive in this particular context. And here is even less

e0037e

intuitive<TT>:-)</TT> If you wish to burn down output generated by an

e0037e

arbitrary program, you can use:

e0037e

dumpsomething | growisofs -Z /dev/scd0=<FONT COLOR="red">/dev/fd/0</FONT>

e0037e

Burning BD-R/DVD±R implies extra limitations:

e0037e

Needless to say that you have only one shot with -Z

e0037e

option<TT>:-)</TT>

e0037e

Apparently media needs to be manually reloaded [ejected and pushed

e0037e

back again] after every burning session (well, if you haven't patched

e0037e

the kernel that is<TT>:-)</TT>

e0037e

--->

e0037e

Unlike DVD+RW, DVD±R media does have notion of multiple

e0037e

sessions. However! Not all legacy units can "see"

e0037e

beyond the first one. Few DVD-ROM units are capable of DVD-R

e0037e

multiborder playback, even fewer support DVD+R multisessioning. In

e0037e

other words  your DVD burner might be the only unit in your vicinity

e0037e

capable to access data added at different occasions.

e0037e

Even if your DVD unit does "sense" multiple sessions,

e0037e

Linux kernel [2.4] sometimes fails to pull that information from the

e0037e

drive<TT>:-(</TT> Till the problem is looked into and resolved you can

e0037e

work it around by reloading corresponding driver, most likely

e0037e

'<TT>rmmod sr_mod</TT>'.

e0037e

Linux kernel 2.6<

e0037e

HREF="http://marc.theaimsgroup.com/?l=linux-kernel&m=110330852622064&w=2">10

e0037e

users might experience

e0037e

HREF="http://marc.theaimsgroup.com/?l=linux-kernel&m=108827602322464&w=2">problems

e0037e

mounting multisession media with last session starting beyond

e0037e

2.2GB boundary. As fast-acting remedy I can suggest to route your unit

e0037e

through ide-scsi, the way it was under 2.4. Even though it's declared

e0037e

unsupported it actually still works in 2.6 (I for one still use it).

e0037e

If you go for BD-R/DVD±R multisessioning, you have to use

e0037e

mkisofs from cdrtools-2.0

e0037e

or later or apply this patch.

e0037e

And when it comes to DVD+R Double Layer and <NOBR>DVD-R</NOBR>

e0037e

Dual Layer recordings, growisofs applies yet another limitation,

e0037e

purely artificial. Taking into consideration Double Layer media prices

e0037e

growisofs is programmed to refuse to perform unappendable

e0037e

recordings which are less than 1/2 of blank capacity and to advice

e0037e

to use single layer media instead.

e0037e

DVD-R Dual Layer multisessioning is not supported for a reason

e0037e

discussed on the -RW companion page. Once

e0037e

again, as of the moment of this writing <NOBR>DVD-R</NOBR> Dual Layer

e0037e

recordings come out unappendable and can not be grown.

e0037e

And once again, do keep in mind that 4.7GB are

e0037e

salesman's GB, i.e. 1000<SUP>3</SUP> and not 1024<SUP>3</SUP>. If

e0037e

translated to "real" GB, single layer

e0037e

<NOBR>DVD±R[W]</NOBR> capacity is not larger than 4.4GiB, and BD

e0037e

- not larger than 23.3GiB! It should also be noted that earlier

e0037e

growisofs versions did not check if there is enough space on media to

e0037e

accommodate the data set to be burned, meaning that it was your sole

e0037e

responsibility to make sure "overburn" condition is not

e0037e

raised. As of version 5.2 growisofs performs the necessary checks

e0037e

for you and refuses to start recording if "overburn"

e0037e

condition appears to be unavoidable. This behaviour can be overridden

e0037e

with <TT>-overburn</TT> command-line option.

e0037e


If you're satisfied with growisofs, then you

e0037e

should just proceed to the next chapter

e0037e

and abstain from applying the optional 2.4.x kernel patch. If

e0037e

you haven't stopped reading beyond this line,

e0037e

HREF="linux-2.4.patch">download the patch, apply it, rebuild  the

e0037e

kernel or modules and re-install (kernel or cdrom.o and sr_mod.o

e0037e

modules, whichever appropriate), but don't ask me

e0037e

HREF="http://www.linuxhq.com/patch-howto.html">how. As you could

e0037e

have noticed, patch targets SCSI CD-ROM module. This means that you

e0037e

have to "route" your IDE unit through ide-scsi to get this one

e0037e

working. To see it in action, insert formatted DVD+RW media and try to

e0037e

access it, '<TT>dd if=/dev/scd<FONT COLOR="red">N</FONT> count=0</TT>'

e0037e

would do. Then verify that kernel logs "<TT>sr

e0037e

COLOR="red">N</FONT>: mmc-3 profile: 1Ah</TT>&quot. You should now be

e0037e

able to '<TT>mkisofs -pad . | dd of=/dev/scd<FONT COLOR="red">N</FONT>

e0037e

obs=32k</TT>' or even '<TT>mke2fs -b 2048 /dev/scd

e0037e

COLOR="red">N</FONT></TT>' and observe kernel logging "<TT>sr

e0037e

COLOR="red">N</FONT>: dirty DVD+RW media</TT>.&quot

e0037e

have to back it out first. The simplest way is probably to restore

e0037e

<TT>drivers/scsi/sr*.[ch]</TT> and <TT>drivers/cdrom/cdrom.c</TT> from

e0037e

your original Linux source code ditribution.-->

e0037e

Linux 2.6 DVD+RW kernel support is planned in

e0037e

line with DVD+MRW kernel support. This [unfortunately] means that

e0037e

industry has to deliver a DVD+MRW capable unit first. Yes, the last

e0037e

sentence means that despite all the promises, there are no such units

e0037e

available on the market yet. As of the 1st of August 2003, Ricoh MP5240A,

e0037e

Philips DVDRW416K or BenQ DW400A do not actually implement

e0037e

Mt.Rainier/EasyWrite support. It remains to be seen if they will offer

e0037e

it in form of firmware upgrade. In either case, the [original] project

e0037e

goal is not only read-write support for DVD+[M]RW capable units

e0037e

themselves, but even playback of DVD+MRW formatted media in legacy

e0037e

DVD-ROM units (when defect list will be read and interpreted by OS

e0037e

software in opposite to Mt.Rainier firmware).

e0037e

Even though kernel now

e0037e

permits to build and mount arbitrary file system, there is one thing you

e0037e

must keep in mind before you just proceed, no matter how

e0037e

tempting it might appear.

e0037e

As you might know DVD+RW media can sustain only

e0037e

around 1000 overwrites. The thing about fully fledged file systems

e0037e

is that every read [or tight bunch of 'em] is accompanied by

e0037e

corresponding i-node update or in other words a write! Now, let's say

e0037e

you lookup the mount point (e.g. ls /mnt/dvd) ten times a day. This

e0037e

gives you a 100 days lifetime on your mountpoint and therefore media.

e0037e

Not really much, huh? So do use <TT>noatime</TT> mount option with

e0037e

DVD+RW media or have it mounted read-only most of the time. However!

e0037e

Every read-write mount "costs" a super-block update. So that

e0037e

if you remount the media say 3 times a day, it would last for about a

e0037e

year [

e0037e

HREF="http://people.mandrakesoft.com/~quintela/supermount/">supermount

e0037e

would exhaust the "budget" way sooner]... Defect management

e0037e

[in firmware, a.k.a.

e0037e

HREF="http://www.licensing.philips.com/information/mtr/">Mt.Rainier,

e0037e

or at file system level] would improve the situation, but ideally

e0037e

file system driver should definitely refrain from modifying the

e0037e

super-block [marking it dirty] if nothing was actually written since

e0037e

last mount. Given the development status of

e0037e

HREF="http://sourceforge.net/projects/linux-udf/">Linux UDF the

e0037e

chances for seeing the latter implemented [for UDF] are more than just

e0037e

conceivable. The request is already filed and even possible solution is

e0037e

being discussed. But why not give UDF a shot already then? By default

e0037e

UDF write support is unfortunately disabled and you might have to

e0037e

reconfigure the kernel and rebuild modules. Alternatively [my preferred

e0037e

option actually] fetch the code at

e0037e

HREF="http://sourceforge.net/projects/linux-udf/">SourceForge and

e0037e

build the module separately. Of course you will have to fetch and build

e0037e

udftools as well. But once it's done just type:

e0037e

mkudffs --spartable=2 --media-type=cdrw /dev/scd<FONT COLOR="red">N</FONT>

e0037e

mount -o rw,noatime /dev/scd<FONT COLOR="red">N</FONT> /mnt/cdrom

e0037e

<TT>mkudffs</TT> command line options were suggested

e0037e

by UDF maintainer, Ben Fennema.

e0037e


Performance optimization. This paragraph

e0037e

applies only if you've patched the kernel. As some of you might

e0037e

remember the original recommendation was "do use <TT>obs=32k</TT>

e0037e

for optimal performance." Well, it was rather naive of me to say

e0037e

so, as common block device layer completely reorganizes the

e0037e

stream so that '<TT>>/dev/scd0</TT>' is as good as '<TT>|dd

e0037e

of=/dev/scd0 obs=32k</TT>'. It should also be noted that dumping to

e0037e

/dev/scd0 puts quite a pressure on VM subsystem, as the data passes

e0037e

through block buffer cache. To minimize the pressure and improve

e0037e

overall system performance bind the cdrom device to a raw device, e.g.

e0037e

'<TT>raw /dev/raw/raw1 /dev/scd0</TT>', growisofs will locate and use

e0037e

it automatically. obs=32k makes perfect sense with /dev/raw devices,

e0037e

but dd (as well as most other programs, e.g. tar) won't work as

e0037e

/dev/raw expects specifically aligned buffer... As temporary

e0037e

workaround, just to get you going so that you can start figuring things

e0037e

out, consider

e0037e

HREF="http://fy.chalmers.se/~appro/LD_*-gallery/index.html?aligned_io#aligned_io">this

e0037e

"hacklet"...

e0037e

Compatibility: caveat lector

e0037e

This paragraph discusses "DVD-ROM

e0037e

compatibility," or playability of already recorded media in legacy

e0037e

units. Blank media compatibility issues, or cases such as failure to

e0037e

start or fulfill recording because of poor media support by burner

e0037e

firmware, are beyond the current scope. Turn to your vendor for list of

e0037e

supported media and/or to the

e0037e

HREF="mailto:cdwrite@other.debian.org">public to share your

e0037e

experience.

e0037e

In order to optimize seek times DVD[-ROM] players

e0037e

calibrate their mechanics every time the media is loaded by sliding

e0037e

the optical head some place, picking up the signal and noting the

e0037e

physical block address underneath the lens. In order for this procedure

e0037e

to work with re-writable/recordable media, that particular spot has to

e0037e

be written to [or de-iced in DVD+RW terms]. Some units slide the head to

e0037e

30mm [radial] to calibrate, some to 35mm. In order to keep such players

e0037e

"happy," make sure that at least 1GB is written [before you

e0037e

attempt to mount it in <NOBR>DVD-ROM</NOBR> unit].

e0037e

Other units attempt to seek to lead-out [or vicinity

e0037e

of it] for calibration purposes. Now the catch is that it's perfectly

e0037e

possible to produce a DVD+RW disc without lead-out. Most notably media

e0037e

initially formatted with <NOBR>dvd+rw-format</NOBR> [apparently]

e0037e

doesn't have any lead-out, not to mention that practically whole

e0037e

surface remains virgin. If you fail to mount/play DVD+RW media, attempt

e0037e

to

e0037e

dvd+rw-format -lead-out /dev/scd

e0037e

COLOR="red">N</FONT>

e0037e

which relocates the lead-out next to outermost

e0037e

written sector as well as makes sure there is no virgin surface before

e0037e

it. Previously written data is not affected by this operation.

e0037e

"experience gathering." I mean the best I can do is to state

e0037e

that my hp dvd200i unit doesn't wipe any data when relocating the

e0037e

lead-out.-->

e0037e

Then non-finalized DVD+R and Sequential

e0037e

<NOBR>DVD-R[W]</NOBR> discs don't have lead-out either<SUP>(*)</SUP>.

e0037e

If you fail to mount/play DVD+R media and wish to sacrifice the

e0037e

remaining space for immediate compatibility, just fill the media

e0037e

up<SUP>(**)</SUP>. Alternatively if you master volume in a single take

e0037e

and don't plan to use it for multisessioning<SUP>(***)</SUP>, you have

e0037e

the option to invoke growisofs with <TT>-dvd-compat</TT> option and cut

e0037e

the real lead-out directly after the first session.

e0037e

<FONT SIZE="-1"><SUP>(*)</SUP></FONT>

e0037e

<FONT SIZE="-1">Well, there are lead-outs at the session edges, but

e0037e

the problem is that "End Physical Sector Number of Data Area"

e0037e

field in "Control Data Zone" of the lead-in contains address

e0037e

of the largest media sector, which makes affected DVD[-ROM] players

e0037e

calibrate at the outermost edge instead of the first session. Actually

e0037e

I fail to understand why don't they burn the address of last sector of

e0037e

the first session in the lead-in even on multisession discs...

e0037e

</FONT>

e0037e

<FONT SIZE="-1"><SUP>(**)</SUP></FONT>

e0037e

<FONT SIZE="-1">But beware the 4GB limit!

e0037e

If 4GB is already an issue, or if you don't feel like throwing

e0037e

unrelated data on the media in question, then invoke '<TT>growisofs

e0037e

<FONT COLOR="red">-M</FONT> /dev/scd0

e0037e

COLOR="red">=/dev/zero</FONT></TT>' (supported by 5.6 and later).

e0037e

Alternative is to re-master the whole volume, naturally with

e0037e

<TT><NOBR>-dvd-compat</NOBR></TT> option.

e0037e

files with '<TT>touch huge<FONT COLOR="red">M</FONT>.void</TT>' and

e0037e

'<TT>perl -e 'truncate ("huge

e0037e

COLOR="red">M</FONT>.void", 0x7ffffffe)'</TT>', and finally to

e0037e

'<TT>growisofs -overburn -M /dev/scd<FONT COLOR="red">N</FONT> ...

e0037e

huge*.void</TT>'. Otherwise you might have to re-master the volume with

e0037e

<TT>-dvd-compat</TT> option.--></FONT>

e0037e

<FONT SIZE="-1"><SUP>(***)</SUP></FONT>

e0037e

<FONT SIZE="-1">E.g. when mastering DVD-Video disc:-) Note that

e0037e

<TT>-dvd-video</TT> option [passed to mkisofs] engages

e0037e

<TT>-dvd-compat</TT> automatically.</FONT>

e0037e

Then we have logical format compatibility

e0037e

issue(s). Probably the very ground for all the controversy around

e0037e

DVD+RW, rather around DVD+RW media not being playable in a whole range

e0037e

of players. DVD+RW Alliance was keen to blame on DVD-ROM vendors, even

e0037e

claiming that they deliberately block playback. But the fact is that

e0037e

format specifications don't explicitly say that unrecognized format

e0037e

[designated by "Book Type" field in "Control Data

e0037e

Zone" of the lead-in] should be treated as <NOBR>DVD-ROM</NOBR>

e0037e

and [in my opinion] it was rather naive of them to claim and expect

e0037e

that the media will be playable in "virtually all players."

e0037e

This deficiency was recognized by practically all DVD+RW vendors [well,

e0037e

apparently by "traditional" DVD+RW vendors and not

e0037e

"latest generation" vendors such as Sony, NEC, TDK...] and a

e0037e

secret vendor-specific command

e0037e

manipulating this "Book Type" field was implemented. So if

e0037e

you fail to mount/play DVD+RW media, you might have an option to

e0037e

dvd+rw-booktype -dvd-rom -media /dev/scd

e0037e

COLOR="red">N</FONT>

e0037e

Once again. Not all vendors support this and you

e0037e

can't expect this utility to work with all recorders.

e0037e

It's naturally not possible to manipulate the

e0037e

"Book Type" field on DVD+R media, that is not after the

e0037e

lead-in is written [which takes place at the moment the first session

e0037e

gets closed]. But it might be possible to control how it [lead-in] is

e0037e

going to be branded by programming the drive in advance:

e0037e

dvd+rw-booktype -dvd-rom -unit+r /dev/scd

e0037e

COLOR="red">N</FONT>

e0037e

Meaning that if you fail to play DVD+R media, you

e0037e

can attempt to burn another disc with more appropriate unit settings.

e0037e

For more background information about dvd+rw-booktype, see

e0037e

HREF="http://www.dvdplusrw.org/Article.asp?aid=42&hl=bitsetting">"Compatibility

e0037e

Bitsettings" article at dvdplusrw.org.

e0037e

There [potentially] are other logical

e0037e

DVD+RW<SUP>(*)</SUP> format incompatibilities, but the "Book

e0037e

Type" issue discussed above is the only one "officially"

e0037e

recognized. Well, it's actually understandable as it's the only one

e0037e

that can be recognized and addressed by a DVD+RW vendor alone.

e0037e

Recognition of other incompatibilities would require cooperation from

e0037e

<NOBR>DVD[-ROM]</NOBR> player vendors and that's something they

e0037e

apparently are not willing to show referring to the fact that DVD+RW

e0037e

format is not approved [and apparently never will be] by

e0037e

HREF="http://www.dvdforum.org/">DVD Forum<SUP>(**)</SUP>.

e0037e

<FONT SIZE="-1"><SUP>(*)</SUP></FONT>

e0037e

<FONT SIZE="-1">Finalized DVD+R media branded with

e0037e

<NOBR>DVD-ROM</NOBR> "Book Type" is virtually identical to

e0037e

<NOBR>DVD-ROM.</NOBR></FONT>

e0037e

<FONT SIZE="-1"><SUP>(**)</SUP></FONT>

e0037e

<FONT SIZE="-1">To which I say "so what?" DVD Forum is an

e0037e

alliance of manufacturers just like DVD+RW Alliance is. It [or any

e0037e

other party for that matter] has no authority to deny a technology

e0037e

development initiative.</FONT>

e0037e

Finally there is a physical incompatibility issue.

e0037e

They claim that there are optical pick-ups out there not being capable

e0037e

to decode the track because of low reflectivity of DVD+RW media

e0037e

surface. I write "they claim," because in the lack of

e0037e

cooperation from <NOBR>DVD[-ROM]</NOBR> vendors it's not possible to

e0037e

distinguish physical from logical format incompatibility, which I find

e0037e

important to tell apart in order to make sure at least logical format

e0037e

incompatibility issues don't persist over time. It might be as trivial

e0037e

as following. As you surely know [already], DVD+RW has same

e0037e

reflectivity as dual-layer <NOBR>DVD-ROM.</NOBR> Now the catch is that

e0037e

the linear pit density in turn is same as of single-layer one. Meaning

e0037e

that if player makes assumptions about linear pit density based on

e0037e

reflectivity, then it won't be able to trace the track... But either

e0037e

way, there is very little you can do about this one, but to try another

e0037e

player...

e0037e

Technical Ramblings

e0037e

ALIGN="RIGHT">

e0037e

As for multisession ISO9660 [DVD]

e0037e

recordings! Unfortunately, Linux ISOFS implementation had certain

e0037e

deficiency which limits interoperability of such recordings. In order

e0037e

to understand it, have a look at sample ISO9660 layout to the right...

e0037e

Now, the problem is that isofs i-nodes<SUP>(*)</SUP> are 32 bits wide

e0037e

(on a 32-bit Linux) and represent offsets of corresponding directory

e0037e

entries (light-greens), byte offsets from the beginning of media. This

e0037e

means that no directory (green areas) may cross 4GB boundary without

e0037e

being effectively corrupted<TT>:-(</TT> It should be noted that in

e0037e

reality it's a bit better than it looks on the picture, as mkisofs

e0037e

collects all the directories in the beginning of any particular session

e0037e

(there normally are no blues between greens). The first session

e0037e

is therefore never subject to i-node wrap-around, but not the

e0037e

subsequent ones! Once again, <FONT COLOR="blue">files</FONT>

e0037e

themselves may reside beyond the <FONT COLOR="brown">4GB</FONT>

e0037e

boundary, but not <FONT COLOR="green">the directories</FONT>, in

e0037e

particular not in further sessions. Having noted that directory entries

e0037e

are actually specified to start at even offsets, I figured that

e0037e

it's perfectly possible to

e0037e

"stretch" the limit to 8GB. But in order to assure

e0037e

maximum interoperability, you should not let any session

e0037e

start past 4GB minus space required for directory

e0037e

structures, e.g. if the last session is to fill the media up, it

e0037e

has to be >400MB. As of version 5.3 growisofs refuses to append

e0037e

a new session beyond 4GB-40MB limit<SUP>(**)</SUP>, where 40MB is

e0037e

pretty much arbitrary chosen large value, large for directory catalogs

e0037e

that is. Yet it doesn't actually guarantee that you can't suffer

e0037e

from i-node wrap-around. Interim fs/isofs 2.4

e0037e

kernel patch was addressed to those who have actually ran into the

e0037e

problem and have to salvage the data. Even though permanent solution

e0037e

for this problem appears in Linux kernel 2.6.8 (thanks to Paul Serice

e0037e

effort), growisofs keeps checking for this 4GB limit in order to ensure

e0037e

broader compatibility of final DVD recordings. This check is not

e0037e

performed for Blu-ray Disc recordings, as probability that a member of

e0037e

such user community would run something elder than 2.6.9 is considered

e0037e

diminishingly low.

e0037e

<FONT SIZE="-1"><SUP>(*)</SUP></FONT>

e0037e

<FONT SIZE="-1">i-node is a number uniquely identifying a single

e0037e

file in a file system</FONT>

e0037e

<FONT SIZE="-1"><SUP>(**)</SUP></FONT>

e0037e

<FONT SIZE="-1">well, as DVD+R Double Layer support was introduced

e0037e

in 5.20, <TT>-use-the-force-luke=4gms</TT> option was added to override

e0037e

this behaviour (naturally recommended for Linux kernel 2.6>=8 users and

e0037e

kernel developers only;-)</FONT>

e0037e

Why media reload is performed after every

e0037e

recording with growisofs? Well, it's performed only if you didn't

e0037e

patch the kernel:-) But no, I do not insist on patching the kernel!

e0037e

All I'm saying is that in the lack of kernel support, media reload is

e0037e

performed for the following reasons. In order to optimize file access

e0037e

kernel maintains so called block cache, so that repetitive requests for

e0037e

same data are met directly from memory and don't result in multiple

e0037e

physical I/O. Now the catch is that block cache layer remains totally

e0037e

unaware of growisofs activities, growisofs bypasses the block

e0037e

cache. This means that block cache inevitably becomes out of sync,

e0037e

which in turn might appear to you as corrupted data. Media reload is

e0037e

performed when flushing the block cache is not an option, e.g. only

e0037e

privileged user is allowed to perform it. Second reason is to force

e0037e

kernel to readjust last addressable block in case it was changed as

e0037e

result of recording. This is done to preclude spurious "attempts to

e0037e

access beyond end of device."

e0037e

What does [kernel] "DVD+RW support"

e0037e

really mean? Even though DVD+RW has no notion of [multiple]

e0037e

sessions, to ensure compatibility with DVD-ROM it's essential to issue

e0037e

"CLOSE TRACK/SESSION (5Bh)"

e0037e

HREF="http://www.t10.org/scsi-3.htm">MMC command to

e0037e

terminate/suspend background formatting (if any in progress) whenever

e0037e

you intend to eject the media or simply stop writing and want better

e0037e

read performance (e.g. remount file system read-only). This is what the

e0037e

patch is basically about: noting when/if media was written to and

e0037e

"finalizing" at unlock door.

e0037e

Secondly, whenever you employ fully fledged

e0037e

file system, I/O requests get inevitably fragmented.

e0037e

"Fragmented" means following. Even though you can address the

e0037e

data with 2KB granularity, it [data] is physically laid out in 32KB

e0037e

chunks. This in turn means that for example writing of 2KB block

e0037e

involves reading of 32KB chunk, replacing corresponding 2KB and writing

e0037e

down of modified 32KB chunk. "Fragmented requests" are those

e0037e

that are smaller than 32KB or/and cross the modulus 32KB boundaries. In

e0037e

order to optimize the process certain caching algorithm is implemented

e0037e

in unit's firmware. Obviously it can't adequately meet all possible

e0037e

situations. And so in such unfortunate situations the drive apparently

e0037e

stops processing I/O requests returning "COMMAND SEQUENCE ERROR

e0037e

(2Ch)" ASC. This is the second essential of "DVD+RW

e0037e

support," namely injecting of "SYNCHRONIZE CACHE (35h)"

e0037e

MMC command in reply to the error condition in question. The command

e0037e

flushes the cached buffers which makes it possible to resume the data

e0037e

flow.

e0037e

Unfortunately the above paragraph doesn't

e0037e

seem to apply to the 1st generation drives, Ricoh MP5120A and

e0037e

derivatives<TT>:-(</TT> "SYNCHRONIZE CACHE (35h)" doesn't

e0037e

seem to be sufficient and the unit keeps replying with "COMMAND

e0037e

SEQUENCE ERROR (2Ch)" going into end-less loop. This makes it

e0037e

impossible to deploy arbitrary file system. I'm open for

e0037e

suggestions... Meanwhile the I've chosen to simply suspend I/O till the

e0037e

media is unmounted. Even 2nd gen unit were reported to exhibit similar

e0037e

[but not the same] behaviour under apparently extremely rare

e0037e

circumstances. At least I failed to reproduce the problem... The problem

e0037e

reportedly disappears with firmware upgrade...

e0037e

Then some [most?] of post-2nd gen units, from

e0037e

most vendors, seem to not bother about complying with

e0037e

<NOBR>DVD+RW</NOBR> specification, "true random write with 2KB

e0037e

granularity" part in particular. Instead they apparently expect

e0037e

host to apply procedure pretty much equivalent to <NOBR>DVD-RW</NOBR>

e0037e

Restricted Overwrite. To be more specific host seems to be expected to

e0037e

coalesce 2KB requests and perform aligned writes at native DVD ECC

e0037e

blocksize, which is 32KB. Formally this should not be required, but

e0037e

it's the reality of marketplace:-(

e0037e

This one really beats me. Sometimes the unit

e0037e

simply stops writing signaling a vendor specific positioning error,

e0037e

03h/15h/82h to be specific. Especially if the media is newly formatted.

e0037e

Couple of work theories. One is that block buffer cache reorders

e0037e

requests so that they are not sequential anymore, "FLUSH

e0037e

CACHE" might do the trick. Another one is that under

e0037e

"underrun" condition background formatting kicks off and has

e0037e

to be explicitly stopped. "Underrun" is in quotes because

e0037e

the unit is supposed to handle temporary data stream outages

e0037e

gracefully. If you run into this (you most likely will), try to

e0037e

complement growisofs command line with [undocumented]

e0037e

<TT>-poor-man</TT> option (which has to be first in the command line).

e0037e

This option eliminates request reorders and minimizes possibility for

e0037e

"underrun" condition (by releasing the pressure off VM

e0037e

subsystem).

e0037e

The original idea was to implement DVD+RW support in

e0037e

drivers/cdrom/cdrom.c. Unfortunately SCSI layer maintains private

e0037e

"writeable" flag controlling the ability to issue WRITE

e0037e

commands. The flag is impossible to reach for from the Unified CD-ROM

e0037e

driver. But why am I talking about SCSI when there are only IDE units

e0037e

out there (at least for the time being)? Well, as you most likely want

e0037e

to occasionally burn even CD-R[W] with cdrecord you want it to go

e0037e

through ide-scsi emulation layer anyway. So I figured that SCSI CD-ROM

e0037e

driver is the one to aim for even for DVD+RW.

e0037e

Unfortunately it was not possible to implement it

e0037e

completely in sr_mod.o<TT>:-(</TT> Minor drivers/cdrom/cdrom.c

e0037e

modification was required to sense the media before decision about

e0037e

whether or not to permit write open. That's because DVD+RW drives are

e0037e

morphing their behaviour after currently mounted media and it's

e0037e

essential to identify newly inserted media.

e0037e

Special comment about "what a dirty

e0037e

hack!!!" To my great surprise it turned out that time-out value you

e0037e

pass in cdrom_generic_command is simply ignored and time-out is set to

e0037e

pre-compiled value of 30 seconds. Unfortunately it's way too low for

e0037e

formatting purposes and I had to do something about it. Alternative to

e0037e

"the dirty hack" was to add another argument to sr_do_ioctl

e0037e

and modify all the calls to it... I've chosen to take over those 31

e0037e

unused bits from the "quiet" argument instead of modifying

e0037e

all the calls (too boring).

e0037e

But even if time-out value passed down to kernel

e0037e

(with either CDROM_SEND_PACKET or SG_IO ioctl) is taken into

e0037e

consideration, it's apparently not interpreted as user-land code

e0037e

expects it to. As I figured... There is no documentation on

e0037e

CDROM_SEND_PACKET, but following the common sense most programmers

e0037e

(including myself:-) expect it to be interpreted in at least

e0037e

platform-independent manner, such as milliseconds maybe? SG_IO timeout

e0037e

in turn is

e0037e

HREF="http://www.torque.net/sg/p/sg_v3_ho.html#AEN215">documented

e0037e

to be measured in milliseconds... Neither of this holds true! Kernel

e0037e

treats these values as "jiffies," which is a

e0037e

platform-dependent value representing time elapsed between timer

e0037e

interrupts. But if we attempt to send down "jiffies," it

e0037e

might turn out wrong too [at least for the moment of this writing]. The

e0037e

catch is that [IA-32] kernel developers figured it's cool to shorten

e0037e

"jiffy," but didn't care to provide user-land with actual

e0037e

value (well, not of actual interest, too much legacy code to deal with)

e0037e

nor scale timeouts

e0037e

accordingly in respect to the legacy value of 10ms.

e0037e

There is another kernel "deficiency" I ran

e0037e

into while working on the (original version of) dvd+rw-format utility.

e0037e

The drive provides background formatting progress status, but

e0037e

unfortunately it's impossible to access it. That's because progress

e0037e

counter is returned [in reply to "TEST UNIT READY"] as

e0037e

"NO SENSE/LOGICAL UNIT NOT READY/FORMAT IN PROGRESS" sense

e0037e

bytes but with "GOOD" status. Apparently any sense data with

e0037e

"GOOD" status is discarded by the common SCSI layer.

e0037e

As you might have noticed the time-out value for

e0037e

"CLOSE SESSION" is 3000 seconds. Does it really take that

e0037e

long? It might... Disappointed? Don't be! It might happen only

e0037e

when reformatting used media. Formatting of the blank

e0037e

media doesn't take longer than a couple of minutes. Reformatting

e0037e

in turn takes as long as it takes to nullify whatever you had on the

e0037e

media which requires corresponding time-outs. But do you have to

e0037e

reformat? Well, only if media contains sensitive data, the new data set

e0037e

is smaller than the current one and (for some reason) will be easier

e0037e

for potentially rival party to get hold of it (in other words when

e0037e

there is a risk for sensitive data to get exposed). Another reason is

e0037e

when you want to reuse the media as a master copy for DVD-ROM

e0037e

manufacturing and want formatted capacity to reflect data set size.

e0037e

Otherwise there is no reason to reformat and as long as you

e0037e

don't you won't be disappointed with how long does it take to

e0037e

"finalize" the media.

e0037e

-->

e0037e

It was pointed out to me that DVD+RW units work with

e0037e

Acard SCSI to

e0037e

IDE bridges.

e0037e

What does

e0037e

HREF="http://www.cdfreaks.com/article/113">plus in DVD+RW/+R

e0037e

stand for? Originally this paragraph started as following:

e0037e

The key feature of DVD+RW/+R media is

e0037e

high [spatial] frequency wobbled [pre-]groove with addressing

e0037e

information modulated into it. This makes it possible to resume

e0037e

interrupted [or deliberately suspended] burning process with accuracy

e0037e

high enough for DVD[-ROM] player not to "notice" anything at

e0037e

playback time. Recovery from buffer underrun condition in DVD-RW/-R

e0037e

case in turn is way less accurate procedure, and the problem is that

e0037e

the provided accuracy is very much what average player can tolerate.

e0037e

Now given that both provided and tolerated inaccuracies are

e0037e

proportional to respectively writing and reading velocities there

e0037e

basically no guarantee that DVD-RW/-R recording that suffered from

e0037e

buffer underrun will be universally playable.

e0037e

Well, it turned out that I was wrong about one

e0037e

thing.

e0037e

to DVD-R[W] to be specific.--> I failed to recognize that DVD-R[W]

e0037e

groove also provides for adequately accurate recovery from

e0037e

buffer underrun condition/lossless linking. Not as accurate as DVD+RW,

e0037e

but accurate enough for splices to be playable in virtually any

e0037e

DVD-ROM/-Video unit. Yet! When it comes to DVD-R[W] recording

e0037e

specificaton apparently insists that you choose between

e0037e

buffer underrun protection and

e0037e

full DVD-ROM/-Video compatibility.

e0037e

The specification asserts that the latter is

e0037e

achieved only in Disc-at-once recording mode and only if data-stream

e0037e

was maintained uninterrupted throughout whole recording. Once again.

e0037e

Even though most vendors implement lossless linking in DAO

e0037e

mode<SUP>(*)</SUP>, full DVD-ROM/-Video compatibility is

e0037e

guaranteed only if recording didn't suffer from buffer underruns. The

e0037e

problem is that "offended" sectors are denoted with certain

e0037e

linking chunk appearing as degraded user data, few bytes, which

e0037e

are supposed to be "corrected away" by ECC

e0037e

procedure<SUP>(**)</SUP>. DVD+ splices are in turn only few bits large

e0037e

and are "accounted" to sync patterns, not to user data

e0037e

area. So that even if suffered from buffer underrun, DVD+ sector is

e0037e

logically indistiguishable from DVD-ROM. Which is why it's commonly

e0037e

referred to that DVD+RW/+R combine DVD-ROM/-Video compatibility with

e0037e

[unconditional] buffer underrun protection.

e0037e

As already mentioned, DVD+ groove has

e0037e

"addressing information modulated into it," ADIP (ADress In

e0037e

Pre-groove). This gives you an advantage of writing DVD+RW in truly

e0037e

arbitrary order, even to virgin surface and practically instantly

e0037e

(after ~40 seconds long initial format procedure). In addition, DVD+RW

e0037e

can be conveniently written to with 2KB granularity<SUP>(***)</SUP>.

e0037e

DVD-RW in turn can only be overwritten in arbitrary order.

e0037e

Meaning that it either has to be completely formatted first (it takes

e0037e

an hour to format 1x media), or initially written to in a sequential

e0037e

manner. And it should also be noted that block overwrite is

e0037e

never an option if DVD-RW media was recorded in [compatible]

e0037e

Disc-at-once or even Incremental mode, only whole disc blanking is.

e0037e

Unlike DVD-R[W], DVD+R[W] recordings can be

e0037e

suspended at any time without any side effects. Consider following

e0037e

scenario. You have a lot of data coming in [at lower rate], which is to

e0037e

be recorded into one file. Meanwhile it turns out that you have to

e0037e

retrieve previously recorded data. This would naturally require

e0037e

suspention of recording. Most notably in DVD-R [and naturally DVD-RW

e0037e

Sequential] case it would result in a hole in the file being recorded.

e0037e

So called linking area, most commonly 32KB gap, has to be introduced.

e0037e

So that you either have to wait till the file is complete or figure out

e0037e

how to deal with holey files. Thanks to ADIP, DVD+R recording is

e0037e

resumed from the very point it was suspended at. In DVD-RW Restricted

e0037e

Overwrite case no gaps are introduced, but if the media was formatted

e0037e

only minimally, suspension/resuming procedure has to be applied and it

e0037e

takes ~40 seconds to perform one. In DVD+RW case, suspension/resuming

e0037e

is instant regardless media state.

e0037e

What does all of the above mean in practice? Well, I

e0037e

was actually hoping that readers would [be able to] figure it out by

e0037e

themselves. Apparently a couple of "guiding" words are

e0037e

needed... It means that it's trivial to employ DVD+RW for housing of

e0037e

live and arbitrary file system, no special modifications to target file

e0037e

system driver are required... Real-time VBR (Variable Bit Rate) Video

e0037e

recordings are children's game...

e0037e

Sometimes DVD+RW/+R recording strategy is referred

e0037e

to as packet writing. I myself am reluctant to call it so (or

e0037e

TAO/SAO/DAO) for the following reason. Despite the fact that DVD-R[W]

e0037e

provides for lossless linking (within a packet/extent only),

e0037e

packets/extents are still denoted with certain linking information

e0037e

which distinguishes it (recording mode in question) from e.g.

e0037e

Disc-at-once. Now the point is that written DVD+RW/+R media, rather its

e0037e

Data Zone, does not contain any linking information and is

e0037e

logically indistinguishable from one written in DVD-R[W] Disc-at-once

e0037e

mode (or DVD-ROM for that matter).

e0037e

It's maintained that signal from DVD+ groove (the

e0037e

one essential for recording, not reading) is much stronger, which makes

e0037e

it quite resistant to dust, scratches, etc.

e0037e

Now we can also discuss differences between

e0037e

Double/Dual Layer implementations. DVD+R Double Layer permits for

e0037e

arbitrary layer break positioning yet maintaining contiguous logical

e0037e

block addressing. In other words address of the block following the

e0037e

break is always address of the block preceding one plus 1, even for

e0037e

arbitrarily positioned break. <NOBR>DVD-R</NOBR> Dual Layer on the

e0037e

other hand implies unconditionally disjoint logical block addressing

e0037e

[for arbitrarily positioned layer break that is]. This is because block

e0037e

addresses as recorded by unit are pre-defined by <NOBR>DVD-dash</NOBR>

e0037e

groove structure. In practice it means that file system layout has to

e0037e

effectively have a hole, which "covers" twice the space between chosen

e0037e

layer break position and outermost edge of the recordable area. And in

e0037e

even more practical terms this means that mastering programs have to be

e0037e

explicitly adapted for <NOBR>DVD-R</NOBR> layer break positioning.

e0037e

Unlike DVD+plus that is.

e0037e

<FONT SIZE="-1"><SUP>(*)</SUP></FONT>

e0037e

<FONT SIZE="-1">According to

e0037e

HREF="ftp://ftp.avc-pioneer.com/Mtfuji_6/Spec/">Mt. Fuji draft

e0037e

buffer underrun protection is not even an option in DVD-R DAO: "If a

e0037e

buffer under-run occurs, the logical unit shall stop

e0037e

writing immediately and the logical unit shall start

e0037e

writing of Lead-out." Protection is defined in Incremental Sequential

e0037e

mode and DVD-RW context. By the way, note that earlier versions of this

e0037e

draft also discuss DVD+RW. You should be aware that they refer to

e0037e

abandoned version which has very little to do with DVD+RW/+R

e0037e

implementation being discussed here.</FONT>

e0037e

<FONT SIZE="-1"><SUP>(**)</SUP></FONT>

e0037e

<FONT SIZE="-1">ECC redundancy does permit for more degradation,

e0037e

more that this linking chunk that is, so that it hadly affects the

e0037e

playability.</FONT>

e0037e

<FONT SIZE="-1"><SUP>(***)</SUP></FONT>

e0037e

<FONT SIZE="-1">DVD "native" block size is 32KB, and 2KB

e0037e

granularity is nothing but a trick, but you're excused from playing it,

e0037e

i.e. reading 32KB, replacing corresponding 2KB and writing 32KB

e0037e

back.</FONT>

e0037e

<SPACER TYPE="block" WIDTH="100%" HEIGHT="100%">

e0037e

</BODY>

e0037e

</HTML>

rpms / dvd+rw-tools

Source Code

Blame SOURCES/index.html

Blu-ray Disc/

by <appro@fy.chalmers.se>,

Foreword

Tutorial

Compatibility: caveat lector

Technical Ramblings