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

rpms / dvd+rw-tools

Blame SOURCES/index.html

Blob History Raw

<HTML>

d00ab9

<HEAD>

d00ab9

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

d00ab9

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

d00ab9

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

d00ab9

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

d00ab9

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

d00ab9

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

d00ab9

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

d00ab9

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

d00ab9

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

d00ab9

			       multisession, growisofs">

d00ab9

				  user-land utilities and optional Linux

d00ab9

				  kernel patch">

d00ab9

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

d00ab9

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

d00ab9

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

d00ab9

</HEAD>

d00ab9

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

d00ab9

Blu-ray Disc/

d00ab9

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

d00ab9

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

d00ab9

by <appro@fy.chalmers.se>,

d00ab9

September 2006

d00ab9

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

d00ab9

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

d00ab9

Q.	What is this page (not) about?

d00ab9

A.<SUP> </SUP>

d00ab9

	Maybe to your disappointment it is not about

d00ab9

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

d00ab9

	computer storage applications of Blu-ray Disc and

d00ab9

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

d00ab9

	exchange... The downloadable files are an optional

d00ab9

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

d00ab9

	couple of user-land utilities dubbed as <NOBR>

d00ab9

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

d00ab9

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

d00ab9

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

d00ab9

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

d00ab9

	is "molded" in an ordinary data file system and

d00ab9

	therefore no explicit support by the burning program is

d00ab9

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

d00ab9

	content preparation which is beyond the scope of this

d00ab9

	page.</FONT>

d00ab9

Q.	Kernel patch? This sounds too complicated

d00ab9

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

d00ab9

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

d00ab9

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

d00ab9

	without explicit kernel support. So if they

d00ab9

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

d00ab9

	patching the kernel is by all means optional. As

d00ab9

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

d00ab9

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

d00ab9

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

d00ab9

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

d00ab9

	7.3 Release Notes say). On additional note Linux kernel

d00ab9

	version 2.6>=10 is equipped with

d00ab9

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

d00ab9

	writing driver which supports even DVD rewritable media,

d00ab9

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

d00ab9

Q.	What is the kernel patch good for then?

d00ab9

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

d00ab9

	write access media and therefore is suitable for housing of an

d00ab9

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

d00ab9

	and this alone, qualifies DVD+RW support for kernel

d00ab9

	implementation. However, I have to recommend to

d00ab9

	deploy it with caution, see tutorial

d00ab9

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

d00ab9

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

d00ab9

	moment of this writing apparenly only 2nd generation

d00ab9

	Ricoh-based units (see

d00ab9

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

d00ab9

	generation listings) equipped with later firmware can sustain

d00ab9

	I/O fragmentation (see Technical Ramblings below for further

d00ab9

	details) and perform reliably.

d00ab9

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

d00ab9

A.	As implied/already mentioned - to master the

d00ab9

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

d00ab9

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

d00ab9

	tutorial below, but figured that couple of words about the

d00ab9

	[original] design ideas behind growisofs, the principal

d00ab9

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

d00ab9

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

d00ab9

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

d00ab9

	likely want to access the data on an arbitrary computer.

d00ab9

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

d00ab9

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

d00ab9

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

d00ab9

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

d00ab9

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

d00ab9

	Well, yes, unless you employ growisofs! Growisofs

d00ab9

	provides the way to both lay down and grow an ISO9660

d00ab9

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

d00ab9

	image to) all supported optical media.

d00ab9

Q.	But if they support  both + and - recording

d00ab9

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

d00ab9

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

d00ab9

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

d00ab9

	vast majority of DVD burners that are being introduced to the

d00ab9

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

d00ab9

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

d00ab9

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

d00ab9

	"seamless" multisessioning, not as reference to some

d00ab9

	particular format:-)

d00ab9

Q.	Do I still need

d00ab9

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

d00ab9

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

d00ab9

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

d00ab9

	actual ISO9660 file system layout. Secondly, the DVD burners

d00ab9

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

d00ab9

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

d00ab9

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

d00ab9

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

d00ab9

	dvd+rw-tools with it/them?

d00ab9

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

d00ab9

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

d00ab9

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

d00ab9

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

d00ab9

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

d00ab9

	dvd+rw-tools provide experimental support even for

d00ab9

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

d00ab9

	dedicated page for further details.

d00ab9

-->

d00ab9

Q.	Does it work with my recorder unit?

d00ab9

A.	If your unit is

d00ab9

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

d00ab9

	then the answer is "most likely it

d00ab9

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

d00ab9

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

d00ab9

	unconditionally "most likely."

d00ab9

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

d00ab9

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

d00ab9

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

d00ab9

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

d00ab9

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

d00ab9

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

d00ab9

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

d00ab9

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

d00ab9

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

d00ab9

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

d00ab9

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

d00ab9

	the least all-mighty

d00ab9

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

d00ab9

Q.	Is there a GUI front-end available for

d00ab9

	dvd+rw-tools?

d00ab9

A.	K3b, version 0.10

d00ab9

	and later, and

d00ab9

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

d00ab9

	version 0.5.1 and later, are both hiding growisofs behind their

d00ab9

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

d00ab9

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

d00ab9

	effort and GUI users should turn elsewhere for end-user

d00ab9

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

d00ab9

	GUI frontends...

d00ab9

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

d00ab9

A.	Version 5.4 adds support for

d00ab9

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

d00ab9

	Version 5.6 adds support for Solaris 2.x

d00ab9

	SIZE=-1>[commercial licensing

d00ab9

	terms for distribution on Solaris are to be settled with

d00ab9

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

d00ab9

	Version 5.8 features

d00ab9

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

d00ab9

	port contributed by Matthew Dillon, FreeBSD Development Team

d00ab9

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

d00ab9

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

d00ab9

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

d00ab9

	5.19, Win32 one - in 6.0,

d00ab9

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

d00ab9

¡

d00ab9

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

d00ab9

	separately available [and unless stated otherwise], do use

d00ab9

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

d00ab9

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

d00ab9

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

d00ab9

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

d00ab9

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

d00ab9

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

d00ab9

	you might have to mount

d00ab9

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

d00ab9

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

d00ab9

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

d00ab9

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

d00ab9

	undergone HP quality assurance testing

d00ab9

	and is delivered on HP

d00ab9

	software depot.</FONT>

d00ab9

Foreword

d00ab9

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

d00ab9

turn to <

d00ab9

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

d00ab9

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

d00ab9

to be subscribed to post

d00ab9

a problem report. List archives can be found at both

d00ab9

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

d00ab9

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

d00ab9

When submitting report, provide versioning information, exact

d00ab9

command line, exact output generated by the program and

d00ab9

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

d00ab9

resulting recording. Do check couple of last

d00ab9

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

d00ab9

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

d00ab9

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

d00ab9

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

d00ab9

attentively...

d00ab9

Special thanks for hardware donations [in

d00ab9

chronological order]:

d00ab9

ALT="Inserve Technology" BORDER=0>

d00ab9

ALT="HP" BORDER=0>

d00ab9

ALT="LinuxFund" BORDER=0>

d00ab9

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

d00ab9

Tutorial

d00ab9


If your burner unit is managed by some

d00ab9

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

d00ab9

automounting/autoplaying facility, such as autofs, supermount,

d00ab9

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

d00ab9

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

d00ab9

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

d00ab9

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

d00ab9

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

d00ab9

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

d00ab9

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

d00ab9

recordings.

d00ab9

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

d00ab9

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

d00ab9

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

d00ab9

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

d00ab9

under their control.</FONT>

d00ab9


Remember to consult

d00ab9

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

d00ab9

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

d00ab9

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

d00ab9

enough to bring it up already here:-)

d00ab9


If you have an IDE unit and run 2.4.x

d00ab9

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

d00ab9

emulation layer by either:

d00ab9

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

d00ab9

argument to kernel;

d00ab9

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

d00ab9

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

d00ab9

pre-install sg modprobe ide-scsi

d00ab9

pre-install sr_mod modprobe ide-scsi

d00ab9

pre-install ide-scsi modprobe ide-cd

d00ab9

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

d00ab9

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

d00ab9

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

d00ab9

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

d00ab9

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

d00ab9

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

d00ab9

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

d00ab9

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

d00ab9

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

d00ab9

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

d00ab9

some IDE chipsets...</FONT>

d00ab9


If you have an external unit, just get

d00ab9

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

d00ab9

whatsoever with USB or

d00ab9

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

d00ab9

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

d00ab9

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

d00ab9

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

d00ab9

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

d00ab9

connected drives were reported to be working fine since eternity.

d00ab9

Firewire connected drives in turn were reported to fail miserably under

d00ab9

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

d00ab9

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

d00ab9

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

d00ab9

work with this and later kernels.

d00ab9


If you're running 2.4.19 or .20, consider

d00ab9

applying this drivers/scsi/sg.c patch.

d00ab9

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

d00ab9

"do" for the following reasons:

d00ab9

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

d00ab9

interface), cdrecord [potentially] is;

d00ab9

I however haven't actually experienced the problem with cdrecord

d00ab9

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

d00ab9

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

d00ab9

failed miserably on me;

d00ab9

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

d00ab9

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

d00ab9

where "generic" SCSI interface can be bypassed by issuing

d00ab9

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

d00ab9

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

d00ab9

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

d00ab9

patches #1 and

d00ab9

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

d00ab9

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

d00ab9

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

d00ab9

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

d00ab9

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

d00ab9

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

d00ab9

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

d00ab9

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

d00ab9

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

d00ab9

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

d00ab9

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

d00ab9

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

d00ab9

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

d00ab9

"supported" recommendation is to just stay away from this

d00ab9

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

d00ab9

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

d00ab9

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

d00ab9

utility works only with limited number of units, installation procedure

d00ab9

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

d00ab9

this security sensitive choice to the end-user.

d00ab9


Download, unpack and compile the

d00ab9

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

d00ab9

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

d00ab9

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

d00ab9

source code files found in the download catalog

d00ab9

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

d00ab9

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

d00ab9

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

d00ab9

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

d00ab9

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

d00ab9

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

d00ab9

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

d00ab9

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

d00ab9

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

d00ab9

CDROM_SEND_PACKET ioctl deployed by dvd+rw-tools.

d00ab9


As new media products and brands are being

d00ab9

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

d00ab9

periodically check for firmware updates. For elder units

d00ab9

firmware update might even be an absolute requirement for using

d00ab9

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

d00ab9

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

d00ab9

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

d00ab9

files in

d00ab9

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

d00ab9

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

d00ab9


Formatting the BD and DVD+RW media.

d00ab9

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

d00ab9

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

d00ab9

formatted. As of version 5.10 growisofs detects blanks and applies

d00ab9

initial formatting procedure automatically. Otherwise same effect can

d00ab9

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

d00ab9

argument to dvd+rw-format. Well,

d00ab9

in BD case it does offer more flexibility than

d00ab9

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

d00ab9

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

d00ab9

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

d00ab9

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

d00ab9

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

d00ab9

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

d00ab9

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

d00ab9

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

d00ab9

so is one of BD.

d00ab9

It was observed that excessive reformats can render

d00ab9

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

d00ab9

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

d00ab9

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

d00ab9

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

d00ab9

Note that re-formatting procedure does not

d00ab9

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

d00ab9

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

d00ab9

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

d00ab9

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

d00ab9

re-formatting is required.

d00ab9

DVD+R media does not require any formatting

d00ab9

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

d00ab9

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

d00ab9

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

d00ab9


Burning with

d00ab9

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

d00ab9

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

d00ab9

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

d00ab9

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

d00ab9

consult mkisofs manual page and

d00ab9

accompanying reference documentation (including multisession related

d00ab9

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

d00ab9

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

d00ab9

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

d00ab9

are:

d00ab9

you may not use -o option;

d00ab9

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

d00ab9

for you;

d00ab9

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

d00ab9

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

d00ab9

Otherwise everything that applies to

d00ab9

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

d00ab9

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

d00ab9

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

d00ab9

them, e.g.:

d00ab9

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

d00ab9

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

d00ab9

Oh! Do make sure you have at least mkisofs

d00ab9

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

d00ab9

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

d00ab9

other words consider deploying growisofs for incremental

d00ab9

multisession backups, then you shall find

d00ab9

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

d00ab9

mkisofs <FONT COLOR="red">2

d00ab9

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

d00ab9

The idea and implementation by

d00ab9

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

d00ab9

"graft" recording sessions as separate directories. Each

d00ab9

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

d00ab9

references to previously backed up ones, which facilitates

d00ab9

comparison between increments as well as fine-graded restore.

d00ab9

Number of users asked about opposite to

d00ab9

multisessioning: multivolume support. Being essentially a recording

d00ab9

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

d00ab9

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

d00ab9

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

d00ab9

shunt. But back to

d00ab9

growisofs...

d00ab9

In addition to intuitive -Z interpretation,

d00ab9

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

d00ab9

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

d00ab9

"magic" command is:

d00ab9

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

d00ab9

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

d00ab9

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

d00ab9

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

d00ab9

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

d00ab9

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

d00ab9

arbitrary program, you can use:

d00ab9

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

d00ab9

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

d00ab9

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

d00ab9

option<TT>:-)</TT>

d00ab9

Apparently media needs to be manually reloaded [ejected and pushed

d00ab9

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

d00ab9

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

d00ab9

--->

d00ab9

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

d00ab9

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

d00ab9

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

d00ab9

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

d00ab9

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

d00ab9

capable to access data added at different occasions.

d00ab9

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

d00ab9

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

d00ab9

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

d00ab9

work it around by reloading corresponding driver, most likely

d00ab9

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

d00ab9

Linux kernel 2.6<

d00ab9

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

d00ab9

users might experience

d00ab9

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

d00ab9

mounting multisession media with last session starting beyond

d00ab9

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

d00ab9

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

d00ab9

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

d00ab9

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

d00ab9

mkisofs from cdrtools-2.0

d00ab9

or later or apply this patch.

d00ab9

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

d00ab9

Dual Layer recordings, growisofs applies yet another limitation,

d00ab9

purely artificial. Taking into consideration Double Layer media prices

d00ab9

growisofs is programmed to refuse to perform unappendable

d00ab9

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

d00ab9

to use single layer media instead.

d00ab9

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

d00ab9

discussed on the -RW companion page. Once

d00ab9

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

d00ab9

recordings come out unappendable and can not be grown.

d00ab9

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

d00ab9

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

d00ab9

translated to "real" GB, single layer

d00ab9

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

d00ab9

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

d00ab9

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

d00ab9

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

d00ab9

responsibility to make sure "overburn" condition is not

d00ab9

raised. As of version 5.2 growisofs performs the necessary checks

d00ab9

for you and refuses to start recording if "overburn"

d00ab9

condition appears to be unavoidable. This behaviour can be overridden

d00ab9

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

d00ab9


If you're satisfied with growisofs, then you

d00ab9

should just proceed to the next chapter

d00ab9

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

d00ab9

you haven't stopped reading beyond this line,

d00ab9

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

d00ab9

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

d00ab9

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

d00ab9

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

d00ab9

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

d00ab9

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

d00ab9

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

d00ab9

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

d00ab9

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

d00ab9

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

d00ab9

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

d00ab9

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

d00ab9

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

d00ab9

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

d00ab9

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

d00ab9

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

d00ab9

your original Linux source code ditribution.-->

d00ab9

Linux 2.6 DVD+RW kernel support is planned in

d00ab9

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

d00ab9

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

d00ab9

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

d00ab9

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

d00ab9

Philips DVDRW416K or BenQ DW400A do not actually implement

d00ab9

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

d00ab9

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

d00ab9

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

d00ab9

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

d00ab9

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

d00ab9

software in opposite to Mt.Rainier firmware).

d00ab9

Even though kernel now

d00ab9

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

d00ab9

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

d00ab9

tempting it might appear.

d00ab9

As you might know DVD+RW media can sustain only

d00ab9

around 1000 overwrites. The thing about fully fledged file systems

d00ab9

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

d00ab9

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

d00ab9

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

d00ab9

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

d00ab9

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

d00ab9

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

d00ab9

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

d00ab9

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

d00ab9

year [

d00ab9

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

d00ab9

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

d00ab9

[in firmware, a.k.a.

d00ab9

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

d00ab9

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

d00ab9

file system driver should definitely refrain from modifying the

d00ab9

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

d00ab9

last mount. Given the development status of

d00ab9

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

d00ab9

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

d00ab9

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

d00ab9

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

d00ab9

UDF write support is unfortunately disabled and you might have to

d00ab9

reconfigure the kernel and rebuild modules. Alternatively [my preferred

d00ab9

option actually] fetch the code at

d00ab9

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

d00ab9

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

d00ab9

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

d00ab9

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

d00ab9

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

d00ab9

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

d00ab9

by UDF maintainer, Ben Fennema.

d00ab9


Performance optimization. This paragraph

d00ab9

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

d00ab9

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

d00ab9

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

d00ab9

so, as common block device layer completely reorganizes the

d00ab9

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

d00ab9

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

d00ab9

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

d00ab9

through block buffer cache. To minimize the pressure and improve

d00ab9

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

d00ab9

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

d00ab9

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

d00ab9

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

d00ab9

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

d00ab9

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

d00ab9

out, consider

d00ab9

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

d00ab9

"hacklet"...

d00ab9

Compatibility: caveat lector

d00ab9

This paragraph discusses "DVD-ROM

d00ab9

compatibility," or playability of already recorded media in legacy

d00ab9

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

d00ab9

start or fulfill recording because of poor media support by burner

d00ab9

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

d00ab9

supported media and/or to the

d00ab9

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

d00ab9

experience.

d00ab9

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

d00ab9

calibrate their mechanics every time the media is loaded by sliding

d00ab9

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

d00ab9

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

d00ab9

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

d00ab9

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

d00ab9

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

d00ab9

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

d00ab9

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

d00ab9

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

d00ab9

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

d00ab9

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

d00ab9

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

d00ab9

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

d00ab9

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

d00ab9

to

d00ab9

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

d00ab9

COLOR="red">N</FONT>

d00ab9

which relocates the lead-out next to outermost

d00ab9

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

d00ab9

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

d00ab9

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

d00ab9

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

d00ab9

lead-out.-->

d00ab9

Then non-finalized DVD+R and Sequential

d00ab9

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

d00ab9

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

d00ab9

remaining space for immediate compatibility, just fill the media

d00ab9

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

d00ab9

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

d00ab9

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

d00ab9

the real lead-out directly after the first session.

d00ab9

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

d00ab9

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

d00ab9

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

d00ab9

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

d00ab9

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

d00ab9

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

d00ab9

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

d00ab9

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

d00ab9

</FONT>

d00ab9

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

d00ab9

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

d00ab9

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

d00ab9

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

d00ab9

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

d00ab9

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

d00ab9

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

d00ab9

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

d00ab9

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

d00ab9

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

d00ab9

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

d00ab9

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

d00ab9

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

d00ab9

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

d00ab9

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

d00ab9

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

d00ab9

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

d00ab9

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

d00ab9

Then we have logical format compatibility

d00ab9

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

d00ab9

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

d00ab9

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

d00ab9

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

d00ab9

format specifications don't explicitly say that unrecognized format

d00ab9

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

d00ab9

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

d00ab9

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

d00ab9

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

d00ab9

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

d00ab9

apparently by "traditional" DVD+RW vendors and not

d00ab9

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

d00ab9

secret vendor-specific command

d00ab9

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

d00ab9

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

d00ab9

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

d00ab9

COLOR="red">N</FONT>

d00ab9

Once again. Not all vendors support this and you

d00ab9

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

d00ab9

It's naturally not possible to manipulate the

d00ab9

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

d00ab9

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

d00ab9

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

d00ab9

going to be branded by programming the drive in advance:

d00ab9

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

d00ab9

COLOR="red">N</FONT>

d00ab9

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

d00ab9

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

d00ab9

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

d00ab9

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

d00ab9

Bitsettings" article at dvdplusrw.org.

d00ab9

There [potentially] are other logical

d00ab9

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

d00ab9

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

d00ab9

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

d00ab9

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

d00ab9

Recognition of other incompatibilities would require cooperation from

d00ab9

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

d00ab9

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

d00ab9

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

d00ab9

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

d00ab9

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

d00ab9

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

d00ab9

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

d00ab9

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

d00ab9

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

d00ab9

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

d00ab9

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

d00ab9

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

d00ab9

development initiative.</FONT>

d00ab9

Finally there is a physical incompatibility issue.

d00ab9

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

d00ab9

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

d00ab9

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

d00ab9

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

d00ab9

distinguish physical from logical format incompatibility, which I find

d00ab9

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

d00ab9

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

d00ab9

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

d00ab9

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

d00ab9

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

d00ab9

that if player makes assumptions about linear pit density based on

d00ab9

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

d00ab9

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

d00ab9

player...

d00ab9

Technical Ramblings

d00ab9

ALIGN="RIGHT">

d00ab9

As for multisession ISO9660 [DVD]

d00ab9

recordings! Unfortunately, Linux ISOFS implementation had certain

d00ab9

deficiency which limits interoperability of such recordings. In order

d00ab9

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

d00ab9

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

d00ab9

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

d00ab9

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

d00ab9

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

d00ab9

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

d00ab9

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

d00ab9

collects all the directories in the beginning of any particular session

d00ab9

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

d00ab9

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

d00ab9

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

d00ab9

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

d00ab9

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

d00ab9

particular not in further sessions. Having noted that directory entries

d00ab9

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

d00ab9

it's perfectly possible to

d00ab9

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

d00ab9

maximum interoperability, you should not let any session

d00ab9

start past 4GB minus space required for directory

d00ab9

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

d00ab9

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

d00ab9

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

d00ab9

pretty much arbitrary chosen large value, large for directory catalogs

d00ab9

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

d00ab9

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

d00ab9

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

d00ab9

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

d00ab9

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

d00ab9

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

d00ab9

broader compatibility of final DVD recordings. This check is not

d00ab9

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

d00ab9

such user community would run something elder than 2.6.9 is considered

d00ab9

diminishingly low.

d00ab9

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

d00ab9

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

d00ab9

file in a file system</FONT>

d00ab9

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

d00ab9

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

d00ab9

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

d00ab9

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

d00ab9

kernel developers only;-)</FONT>

d00ab9

Why media reload is performed after every

d00ab9

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

d00ab9

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

d00ab9

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

d00ab9

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

d00ab9

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

d00ab9

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

d00ab9

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

d00ab9

unaware of growisofs activities, growisofs bypasses the block

d00ab9

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

d00ab9

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

d00ab9

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

d00ab9

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

d00ab9

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

d00ab9

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

d00ab9

access beyond end of device."

d00ab9

What does [kernel] "DVD+RW support"

d00ab9

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

d00ab9

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

d00ab9

"CLOSE TRACK/SESSION (5Bh)"

d00ab9

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

d00ab9

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

d00ab9

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

d00ab9

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

d00ab9

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

d00ab9

"finalizing" at unlock door.

d00ab9

Secondly, whenever you employ fully fledged

d00ab9

file system, I/O requests get inevitably fragmented.

d00ab9

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

d00ab9

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

d00ab9

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

d00ab9

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

d00ab9

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

d00ab9

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

d00ab9

order to optimize the process certain caching algorithm is implemented

d00ab9

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

d00ab9

situations. And so in such unfortunate situations the drive apparently

d00ab9

stops processing I/O requests returning "COMMAND SEQUENCE ERROR

d00ab9

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

d00ab9

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

d00ab9

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

d00ab9

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

d00ab9

flow.

d00ab9

Unfortunately the above paragraph doesn't

d00ab9

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

d00ab9

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

d00ab9

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

d00ab9

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

d00ab9

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

d00ab9

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

d00ab9

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

d00ab9

[but not the same] behaviour under apparently extremely rare

d00ab9

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

d00ab9

reportedly disappears with firmware upgrade...

d00ab9

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

d00ab9

most vendors, seem to not bother about complying with

d00ab9

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

d00ab9

granularity" part in particular. Instead they apparently expect

d00ab9

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

d00ab9

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

d00ab9

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

d00ab9

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

d00ab9

it's the reality of marketplace:-(

d00ab9

This one really beats me. Sometimes the unit

d00ab9

simply stops writing signaling a vendor specific positioning error,

d00ab9

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

d00ab9

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

d00ab9

requests so that they are not sequential anymore, "FLUSH

d00ab9

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

d00ab9

"underrun" condition background formatting kicks off and has

d00ab9

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

d00ab9

the unit is supposed to handle temporary data stream outages

d00ab9

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

d00ab9

complement growisofs command line with [undocumented]

d00ab9

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

d00ab9

This option eliminates request reorders and minimizes possibility for

d00ab9

"underrun" condition (by releasing the pressure off VM

d00ab9

subsystem).

d00ab9

The original idea was to implement DVD+RW support in

d00ab9

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

d00ab9

"writeable" flag controlling the ability to issue WRITE

d00ab9

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

d00ab9

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

d00ab9

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

d00ab9

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

d00ab9

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

d00ab9

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

d00ab9

Unfortunately it was not possible to implement it

d00ab9

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

d00ab9

modification was required to sense the media before decision about

d00ab9

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

d00ab9

morphing their behaviour after currently mounted media and it's

d00ab9

essential to identify newly inserted media.

d00ab9

Special comment about "what a dirty

d00ab9

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

d00ab9

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

d00ab9

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

d00ab9

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

d00ab9

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

d00ab9

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

d00ab9

unused bits from the "quiet" argument instead of modifying

d00ab9

all the calls (too boring).

d00ab9

But even if time-out value passed down to kernel

d00ab9

(with either CDROM_SEND_PACKET or SG_IO ioctl) is taken into

d00ab9

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

d00ab9

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

d00ab9

CDROM_SEND_PACKET, but following the common sense most programmers

d00ab9

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

d00ab9

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

d00ab9

in turn is

d00ab9

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

d00ab9

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

d00ab9

treats these values as "jiffies," which is a

d00ab9

platform-dependent value representing time elapsed between timer

d00ab9

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

d00ab9

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

d00ab9

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

d00ab9

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

d00ab9

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

d00ab9

nor scale timeouts

d00ab9

accordingly in respect to the legacy value of 10ms.

d00ab9

There is another kernel "deficiency" I ran

d00ab9

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

d00ab9

The drive provides background formatting progress status, but

d00ab9

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

d00ab9

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

d00ab9

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

d00ab9

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

d00ab9

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

d00ab9

As you might have noticed the time-out value for

d00ab9

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

d00ab9

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

d00ab9

when reformatting used media. Formatting of the blank

d00ab9

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

d00ab9

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

d00ab9

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

d00ab9

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

d00ab9

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

d00ab9

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

d00ab9

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

d00ab9

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

d00ab9

manufacturing and want formatted capacity to reflect data set size.

d00ab9

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

d00ab9

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

d00ab9

"finalize" the media.

d00ab9

-->

d00ab9

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

d00ab9

Acard SCSI to

d00ab9

IDE bridges.

d00ab9

What does

d00ab9

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

d00ab9

stand for? Originally this paragraph started as following:

d00ab9

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

d00ab9

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

d00ab9

information modulated into it. This makes it possible to resume

d00ab9

interrupted [or deliberately suspended] burning process with accuracy

d00ab9

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

d00ab9

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

d00ab9

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

d00ab9

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

d00ab9

Now given that both provided and tolerated inaccuracies are

d00ab9

proportional to respectively writing and reading velocities there

d00ab9

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

d00ab9

buffer underrun will be universally playable.

d00ab9

Well, it turned out that I was wrong about one

d00ab9

thing.

d00ab9

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

d00ab9

groove also provides for adequately accurate recovery from

d00ab9

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

d00ab9

but accurate enough for splices to be playable in virtually any

d00ab9

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

d00ab9

specificaton apparently insists that you choose between

d00ab9

buffer underrun protection and

d00ab9

full DVD-ROM/-Video compatibility.

d00ab9

The specification asserts that the latter is

d00ab9

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

d00ab9

was maintained uninterrupted throughout whole recording. Once again.

d00ab9

Even though most vendors implement lossless linking in DAO

d00ab9

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

d00ab9

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

d00ab9

problem is that "offended" sectors are denoted with certain

d00ab9

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

d00ab9

are supposed to be "corrected away" by ECC

d00ab9

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

d00ab9

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

d00ab9

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

d00ab9

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

d00ab9

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

d00ab9

[unconditional] buffer underrun protection.

d00ab9

As already mentioned, DVD+ groove has

d00ab9

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

d00ab9

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

d00ab9

arbitrary order, even to virgin surface and practically instantly

d00ab9

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

d00ab9

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

d00ab9

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

d00ab9

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

d00ab9

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

d00ab9

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

d00ab9

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

d00ab9

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

d00ab9

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

d00ab9

suspended at any time without any side effects. Consider following

d00ab9

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

d00ab9

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

d00ab9

retrieve previously recorded data. This would naturally require

d00ab9

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

d00ab9

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

d00ab9

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

d00ab9

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

d00ab9

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

d00ab9

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

d00ab9

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

d00ab9

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

d00ab9

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

d00ab9

is instant regardless media state.

d00ab9

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

d00ab9

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

d00ab9

themselves. Apparently a couple of "guiding" words are

d00ab9

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

d00ab9

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

d00ab9

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

d00ab9

recordings are children's game...

d00ab9

Sometimes DVD+RW/+R recording strategy is referred

d00ab9

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

d00ab9

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

d00ab9

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

d00ab9

packets/extents are still denoted with certain linking information

d00ab9

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

d00ab9

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

d00ab9

Data Zone, does not contain any linking information and is

d00ab9

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

d00ab9

mode (or DVD-ROM for that matter).

d00ab9

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

d00ab9

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

d00ab9

it quite resistant to dust, scratches, etc.

d00ab9

Now we can also discuss differences between

d00ab9

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

d00ab9

arbitrary layer break positioning yet maintaining contiguous logical

d00ab9

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

d00ab9

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

d00ab9

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

d00ab9

other hand implies unconditionally disjoint logical block addressing

d00ab9

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

d00ab9

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

d00ab9

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

d00ab9

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

d00ab9

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

d00ab9

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

d00ab9

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

d00ab9

Unlike DVD+plus that is.

d00ab9

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

d00ab9

<FONT SIZE="-1">According to

d00ab9

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

d00ab9

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

d00ab9

buffer under-run occurs, the logical unit shall stop

d00ab9

writing immediately and the logical unit shall start

d00ab9

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

d00ab9

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

d00ab9

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

d00ab9

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

d00ab9

implementation being discussed here.</FONT>

d00ab9

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

d00ab9

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

d00ab9

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

d00ab9

playability.</FONT>

d00ab9

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

d00ab9

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

d00ab9

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

d00ab9

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

d00ab9

back.</FONT>

d00ab9

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

d00ab9

</BODY>

d00ab9

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