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

rpms / dvd+rw-tools

Blame SOURCES/index.html

Blob History Raw

<HTML>

eaee06

<HEAD>

eaee06

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

eaee06

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

eaee06

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

eaee06

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

eaee06

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

eaee06

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

eaee06

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

eaee06

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

eaee06

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

eaee06

			       multisession, growisofs">

eaee06

				  user-land utilities and optional Linux

eaee06

				  kernel patch">

eaee06

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

eaee06

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

eaee06

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

eaee06

</HEAD>

eaee06

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

eaee06

Blu-ray Disc/

eaee06

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

eaee06

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

eaee06

by <appro@fy.chalmers.se>,

eaee06

September 2006

eaee06

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

eaee06

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

eaee06

Q.	What is this page (not) about?

eaee06

A.<SUP> </SUP>

eaee06

	Maybe to your disappointment it is not about

eaee06

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

eaee06

	computer storage applications of Blu-ray Disc and

eaee06

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

eaee06

	exchange... The downloadable files are an optional

eaee06

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

eaee06

	couple of user-land utilities dubbed as <NOBR>

eaee06

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

eaee06

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

eaee06

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

eaee06

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

eaee06

	is "molded" in an ordinary data file system and

eaee06

	therefore no explicit support by the burning program is

eaee06

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

eaee06

	content preparation which is beyond the scope of this

eaee06

	page.</FONT>

eaee06

Q.	Kernel patch? This sounds too complicated

eaee06

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

eaee06

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

eaee06

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

eaee06

	without explicit kernel support. So if they

eaee06

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

eaee06

	patching the kernel is by all means optional. As

eaee06

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

eaee06

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

eaee06

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

eaee06

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

eaee06

	7.3 Release Notes say). On additional note Linux kernel

eaee06

	version 2.6>=10 is equipped with

eaee06

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

eaee06

	writing driver which supports even DVD rewritable media,

eaee06

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

eaee06

Q.	What is the kernel patch good for then?

eaee06

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

eaee06

	write access media and therefore is suitable for housing of an

eaee06

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

eaee06

	and this alone, qualifies DVD+RW support for kernel

eaee06

	implementation. However, I have to recommend to

eaee06

	deploy it with caution, see tutorial

eaee06

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

eaee06

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

eaee06

	moment of this writing apparenly only 2nd generation

eaee06

	Ricoh-based units (see

eaee06

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

eaee06

	generation listings) equipped with later firmware can sustain

eaee06

	I/O fragmentation (see Technical Ramblings below for further

eaee06

	details) and perform reliably.

eaee06

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

eaee06

A.	As implied/already mentioned - to master the

eaee06

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

eaee06

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

eaee06

	tutorial below, but figured that couple of words about the

eaee06

	[original] design ideas behind growisofs, the principal

eaee06

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

eaee06

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

eaee06

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

eaee06

	likely want to access the data on an arbitrary computer.

eaee06

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

eaee06

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

eaee06

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

eaee06

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

eaee06

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

eaee06

	Well, yes, unless you employ growisofs! Growisofs

eaee06

	provides the way to both lay down and grow an ISO9660

eaee06

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

eaee06

	image to) all supported optical media.

eaee06

Q.	But if they support  both + and - recording

eaee06

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

eaee06

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

eaee06

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

eaee06

	vast majority of DVD burners that are being introduced to the

eaee06

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

eaee06

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

eaee06

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

eaee06

	"seamless" multisessioning, not as reference to some

eaee06

	particular format:-)

eaee06

Q.	Do I still need

eaee06

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

eaee06

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

eaee06

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

eaee06

	actual ISO9660 file system layout. Secondly, the DVD burners

eaee06

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

eaee06

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

eaee06

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

eaee06

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

eaee06

	dvd+rw-tools with it/them?

eaee06

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

eaee06

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

eaee06

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

eaee06

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

eaee06

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

eaee06

	dvd+rw-tools provide experimental support even for

eaee06

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

eaee06

	dedicated page for further details.

eaee06

-->

eaee06

Q.	Does it work with my recorder unit?

eaee06

A.	If your unit is

eaee06

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

eaee06

	then the answer is "most likely it

eaee06

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

eaee06

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

eaee06

	unconditionally "most likely."

eaee06

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

eaee06

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

eaee06

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

eaee06

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

eaee06

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

eaee06

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

eaee06

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

eaee06

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

eaee06

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

eaee06

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

eaee06

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

eaee06

	the least all-mighty

eaee06

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

eaee06

Q.	Is there a GUI front-end available for

eaee06

	dvd+rw-tools?

eaee06

A.	K3b, version 0.10

eaee06

	and later, and

eaee06

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

eaee06

	version 0.5.1 and later, are both hiding growisofs behind their

eaee06

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

eaee06

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

eaee06

	effort and GUI users should turn elsewhere for end-user

eaee06

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

eaee06

	GUI frontends...

eaee06

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

eaee06

A.	Version 5.4 adds support for

eaee06

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

eaee06

	Version 5.6 adds support for Solaris 2.x

eaee06

	SIZE=-1>[commercial licensing

eaee06

	terms for distribution on Solaris are to be settled with

eaee06

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

eaee06

	Version 5.8 features

eaee06

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

eaee06

	port contributed by Matthew Dillon, FreeBSD Development Team

eaee06

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

eaee06

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

eaee06

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

eaee06

	5.19, Win32 one - in 6.0,

eaee06

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

eaee06

¡

eaee06

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

eaee06

	separately available [and unless stated otherwise], do use

eaee06

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

eaee06

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

eaee06

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

eaee06

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

eaee06

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

eaee06

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

eaee06

	you might have to mount

eaee06

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

eaee06

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

eaee06

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

eaee06

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

eaee06

	undergone HP quality assurance testing

eaee06

	and is delivered on HP

eaee06

	software depot.</FONT>

eaee06

Foreword

eaee06

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

eaee06

turn to <

eaee06

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

eaee06

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

eaee06

to be subscribed to post

eaee06

a problem report. List archives can be found at both

eaee06

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

eaee06

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

eaee06

When submitting report, provide versioning information, exact

eaee06

command line, exact output generated by the program and

eaee06

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

eaee06

resulting recording. Do check couple of last

eaee06

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

eaee06

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

eaee06

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

eaee06

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

eaee06

attentively...

eaee06

Special thanks for hardware donations [in

eaee06

chronological order]:

eaee06

ALT="Inserve Technology" BORDER=0>

eaee06

ALT="HP" BORDER=0>

eaee06

ALT="LinuxFund" BORDER=0>

eaee06

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

eaee06

Tutorial

eaee06


If your burner unit is managed by some

eaee06

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

eaee06

automounting/autoplaying facility, such as autofs, supermount,

eaee06

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

eaee06

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

eaee06

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

eaee06

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

eaee06

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

eaee06

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

eaee06

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

eaee06

recordings.

eaee06

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

eaee06

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

eaee06

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

eaee06

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

eaee06

under their control.</FONT>

eaee06


Remember to consult

eaee06

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

eaee06

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

eaee06

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

eaee06

enough to bring it up already here:-)

eaee06


If you have an IDE unit and run 2.4.x

eaee06

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

eaee06

emulation layer by either:

eaee06

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

eaee06

argument to kernel;

eaee06

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

eaee06

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

eaee06

pre-install sg modprobe ide-scsi

eaee06

pre-install sr_mod modprobe ide-scsi

eaee06

pre-install ide-scsi modprobe ide-cd

eaee06

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

eaee06

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

eaee06

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

eaee06

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

eaee06

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

eaee06

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

eaee06

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

eaee06

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

eaee06

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

eaee06

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

eaee06

some IDE chipsets...</FONT>

eaee06


If you have an external unit, just get

eaee06

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

eaee06

whatsoever with USB or

eaee06

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

eaee06

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

eaee06

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

eaee06

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

eaee06

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

eaee06

connected drives were reported to be working fine since eternity.

eaee06

Firewire connected drives in turn were reported to fail miserably under

eaee06

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

eaee06

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

eaee06

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

eaee06

work with this and later kernels.

eaee06


If you're running 2.4.19 or .20, consider

eaee06

applying this drivers/scsi/sg.c patch.

eaee06

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

eaee06

"do" for the following reasons:

eaee06

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

eaee06

interface), cdrecord [potentially] is;

eaee06

I however haven't actually experienced the problem with cdrecord

eaee06

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

eaee06

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

eaee06

failed miserably on me;

eaee06

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

eaee06

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

eaee06

where "generic" SCSI interface can be bypassed by issuing

eaee06

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

eaee06

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

eaee06

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

eaee06

patches #1 and

eaee06

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

eaee06

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

eaee06

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

eaee06

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

eaee06

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

eaee06

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

eaee06

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

eaee06

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

eaee06

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

eaee06

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

eaee06

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

eaee06

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

eaee06

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

eaee06

"supported" recommendation is to just stay away from this

eaee06

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

eaee06

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

eaee06

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

eaee06

utility works only with limited number of units, installation procedure

eaee06

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

eaee06

this security sensitive choice to the end-user.

eaee06


Download, unpack and compile the

eaee06

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

eaee06

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

eaee06

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

eaee06

source code files found in the download catalog

eaee06

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

eaee06

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

eaee06

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

eaee06

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

eaee06

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

eaee06

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

eaee06

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

eaee06

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

eaee06

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

eaee06

CDROM_SEND_PACKET ioctl deployed by dvd+rw-tools.

eaee06


As new media products and brands are being

eaee06

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

eaee06

periodically check for firmware updates. For elder units

eaee06

firmware update might even be an absolute requirement for using

eaee06

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

eaee06

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

eaee06

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

eaee06

files in

eaee06

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

eaee06

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

eaee06


Formatting the BD and DVD+RW media.

eaee06

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

eaee06

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

eaee06

formatted. As of version 5.10 growisofs detects blanks and applies

eaee06

initial formatting procedure automatically. Otherwise same effect can

eaee06

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

eaee06

argument to dvd+rw-format. Well,

eaee06

in BD case it does offer more flexibility than

eaee06

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

eaee06

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

eaee06

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

eaee06

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

eaee06

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

eaee06

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

eaee06

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

eaee06

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

eaee06

so is one of BD.

eaee06

It was observed that excessive reformats can render

eaee06

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

eaee06

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

eaee06

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

eaee06

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

eaee06

Note that re-formatting procedure does not

eaee06

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

eaee06

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

eaee06

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

eaee06

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

eaee06

re-formatting is required.

eaee06

DVD+R media does not require any formatting

eaee06

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

eaee06

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

eaee06

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

eaee06


Burning with

eaee06

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

eaee06

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

eaee06

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

eaee06

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

eaee06

consult mkisofs manual page and

eaee06

accompanying reference documentation (including multisession related

eaee06

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

eaee06

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

eaee06

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

eaee06

are:

eaee06

you may not use -o option;

eaee06

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

eaee06

for you;

eaee06

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

eaee06

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

eaee06

Otherwise everything that applies to

eaee06

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

eaee06

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

eaee06

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

eaee06

them, e.g.:

eaee06

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

eaee06

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

eaee06

Oh! Do make sure you have at least mkisofs

eaee06

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

eaee06

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

eaee06

other words consider deploying growisofs for incremental

eaee06

multisession backups, then you shall find

eaee06

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

eaee06

mkisofs <FONT COLOR="red">2

eaee06

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

eaee06

The idea and implementation by

eaee06

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

eaee06

"graft" recording sessions as separate directories. Each

eaee06

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

eaee06

references to previously backed up ones, which facilitates

eaee06

comparison between increments as well as fine-graded restore.

eaee06

Number of users asked about opposite to

eaee06

multisessioning: multivolume support. Being essentially a recording

eaee06

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

eaee06

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

eaee06

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

eaee06

shunt. But back to

eaee06

growisofs...

eaee06

In addition to intuitive -Z interpretation,

eaee06

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

eaee06

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

eaee06

"magic" command is:

eaee06

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

eaee06

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

eaee06

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

eaee06

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

eaee06

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

eaee06

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

eaee06

arbitrary program, you can use:

eaee06

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

eaee06

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

eaee06

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

eaee06

option<TT>:-)</TT>

eaee06

Apparently media needs to be manually reloaded [ejected and pushed

eaee06

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

eaee06

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

eaee06

--->

eaee06

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

eaee06

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

eaee06

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

eaee06

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

eaee06

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

eaee06

capable to access data added at different occasions.

eaee06

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

eaee06

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

eaee06

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

eaee06

work it around by reloading corresponding driver, most likely

eaee06

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

eaee06

Linux kernel 2.6<

eaee06

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

eaee06

users might experience

eaee06

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

eaee06

mounting multisession media with last session starting beyond

eaee06

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

eaee06

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

eaee06

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

eaee06

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

eaee06

mkisofs from cdrtools-2.0

eaee06

or later or apply this patch.

eaee06

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

eaee06

Dual Layer recordings, growisofs applies yet another limitation,

eaee06

purely artificial. Taking into consideration Double Layer media prices

eaee06

growisofs is programmed to refuse to perform unappendable

eaee06

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

eaee06

to use single layer media instead.

eaee06

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

eaee06

discussed on the -RW companion page. Once

eaee06

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

eaee06

recordings come out unappendable and can not be grown.

eaee06

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

eaee06

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

eaee06

translated to "real" GB, single layer

eaee06

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

eaee06

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

eaee06

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

eaee06

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

eaee06

responsibility to make sure "overburn" condition is not

eaee06

raised. As of version 5.2 growisofs performs the necessary checks

eaee06

for you and refuses to start recording if "overburn"

eaee06

condition appears to be unavoidable. This behaviour can be overridden

eaee06

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

eaee06


If you're satisfied with growisofs, then you

eaee06

should just proceed to the next chapter

eaee06

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

eaee06

you haven't stopped reading beyond this line,

eaee06

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

eaee06

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

eaee06

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

eaee06

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

eaee06

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

eaee06

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

eaee06

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

eaee06

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

eaee06

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

eaee06

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

eaee06

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

eaee06

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

eaee06

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

eaee06

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

eaee06

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

eaee06

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

eaee06

your original Linux source code ditribution.-->

eaee06

Linux 2.6 DVD+RW kernel support is planned in

eaee06

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

eaee06

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

eaee06

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

eaee06

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

eaee06

Philips DVDRW416K or BenQ DW400A do not actually implement

eaee06

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

eaee06

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

eaee06

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

eaee06

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

eaee06

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

eaee06

software in opposite to Mt.Rainier firmware).

eaee06

Even though kernel now

eaee06

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

eaee06

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

eaee06

tempting it might appear.

eaee06

As you might know DVD+RW media can sustain only

eaee06

around 1000 overwrites. The thing about fully fledged file systems

eaee06

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

eaee06

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

eaee06

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

eaee06

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

eaee06

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

eaee06

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

eaee06

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

eaee06

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

eaee06

year [

eaee06

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

eaee06

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

eaee06

[in firmware, a.k.a.

eaee06

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

eaee06

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

eaee06

file system driver should definitely refrain from modifying the

eaee06

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

eaee06

last mount. Given the development status of

eaee06

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

eaee06

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

eaee06

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

eaee06

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

eaee06

UDF write support is unfortunately disabled and you might have to

eaee06

reconfigure the kernel and rebuild modules. Alternatively [my preferred

eaee06

option actually] fetch the code at

eaee06

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

eaee06

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

eaee06

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

eaee06

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

eaee06

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

eaee06

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

eaee06

by UDF maintainer, Ben Fennema.

eaee06


Performance optimization. This paragraph

eaee06

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

eaee06

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

eaee06

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

eaee06

so, as common block device layer completely reorganizes the

eaee06

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

eaee06

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

eaee06

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

eaee06

through block buffer cache. To minimize the pressure and improve

eaee06

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

eaee06

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

eaee06

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

eaee06

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

eaee06

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

eaee06

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

eaee06

out, consider

eaee06

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

eaee06

"hacklet"...

eaee06

Compatibility: caveat lector

eaee06

This paragraph discusses "DVD-ROM

eaee06

compatibility," or playability of already recorded media in legacy

eaee06

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

eaee06

start or fulfill recording because of poor media support by burner

eaee06

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

eaee06

supported media and/or to the

eaee06

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

eaee06

experience.

eaee06

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

eaee06

calibrate their mechanics every time the media is loaded by sliding

eaee06

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

eaee06

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

eaee06

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

eaee06

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

eaee06

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

eaee06

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

eaee06

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

eaee06

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

eaee06

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

eaee06

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

eaee06

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

eaee06

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

eaee06

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

eaee06

to

eaee06

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

eaee06

COLOR="red">N</FONT>

eaee06

which relocates the lead-out next to outermost

eaee06

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

eaee06

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

eaee06

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

eaee06

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

eaee06

lead-out.-->

eaee06

Then non-finalized DVD+R and Sequential

eaee06

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

eaee06

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

eaee06

remaining space for immediate compatibility, just fill the media

eaee06

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

eaee06

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

eaee06

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

eaee06

the real lead-out directly after the first session.

eaee06

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

eaee06

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

eaee06

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

eaee06

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

eaee06

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

eaee06

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

eaee06

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

eaee06

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

eaee06

</FONT>

eaee06

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

eaee06

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

eaee06

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

eaee06

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

eaee06

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

eaee06

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

eaee06

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

eaee06

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

eaee06

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

eaee06

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

eaee06

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

eaee06

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

eaee06

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

eaee06

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

eaee06

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

eaee06

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

eaee06

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

eaee06

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

eaee06

Then we have logical format compatibility

eaee06

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

eaee06

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

eaee06

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

eaee06

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

eaee06

format specifications don't explicitly say that unrecognized format

eaee06

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

eaee06

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

eaee06

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

eaee06

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

eaee06

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

eaee06

apparently by "traditional" DVD+RW vendors and not

eaee06

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

eaee06

secret vendor-specific command

eaee06

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

eaee06

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

eaee06

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

eaee06

COLOR="red">N</FONT>

eaee06

Once again. Not all vendors support this and you

eaee06

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

eaee06

It's naturally not possible to manipulate the

eaee06

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

eaee06

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

eaee06

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

eaee06

going to be branded by programming the drive in advance:

eaee06

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

eaee06

COLOR="red">N</FONT>

eaee06

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

eaee06

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

eaee06

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

eaee06

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

eaee06

Bitsettings" article at dvdplusrw.org.

eaee06

There [potentially] are other logical

eaee06

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

eaee06

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

eaee06

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

eaee06

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

eaee06

Recognition of other incompatibilities would require cooperation from

eaee06

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

eaee06

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

eaee06

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

eaee06

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

eaee06

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

eaee06

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

eaee06

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

eaee06

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

eaee06

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

eaee06

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

eaee06

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

eaee06

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

eaee06

development initiative.</FONT>

eaee06

Finally there is a physical incompatibility issue.

eaee06

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

eaee06

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

eaee06

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

eaee06

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

eaee06

distinguish physical from logical format incompatibility, which I find

eaee06

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

eaee06

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

eaee06

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

eaee06

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

eaee06

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

eaee06

that if player makes assumptions about linear pit density based on

eaee06

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

eaee06

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

eaee06

player...

eaee06

Technical Ramblings

eaee06

ALIGN="RIGHT">

eaee06

As for multisession ISO9660 [DVD]

eaee06

recordings! Unfortunately, Linux ISOFS implementation had certain

eaee06

deficiency which limits interoperability of such recordings. In order

eaee06

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

eaee06

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

eaee06

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

eaee06

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

eaee06

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

eaee06

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

eaee06

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

eaee06

collects all the directories in the beginning of any particular session

eaee06

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

eaee06

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

eaee06

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

eaee06

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

eaee06

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

eaee06

particular not in further sessions. Having noted that directory entries

eaee06

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

eaee06

it's perfectly possible to

eaee06

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

eaee06

maximum interoperability, you should not let any session

eaee06

start past 4GB minus space required for directory

eaee06

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

eaee06

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

eaee06

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

eaee06

pretty much arbitrary chosen large value, large for directory catalogs

eaee06

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

eaee06

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

eaee06

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

eaee06

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

eaee06

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

eaee06

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

eaee06

broader compatibility of final DVD recordings. This check is not

eaee06

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

eaee06

such user community would run something elder than 2.6.9 is considered

eaee06

diminishingly low.

eaee06

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

eaee06

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

eaee06

file in a file system</FONT>

eaee06

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

eaee06

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

eaee06

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

eaee06

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

eaee06

kernel developers only;-)</FONT>

eaee06

Why media reload is performed after every

eaee06

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

eaee06

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

eaee06

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

eaee06

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

eaee06

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

eaee06

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

eaee06

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

eaee06

unaware of growisofs activities, growisofs bypasses the block

eaee06

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

eaee06

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

eaee06

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

eaee06

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

eaee06

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

eaee06

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

eaee06

access beyond end of device."

eaee06

What does [kernel] "DVD+RW support"

eaee06

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

eaee06

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

eaee06

"CLOSE TRACK/SESSION (5Bh)"

eaee06

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

eaee06

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

eaee06

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

eaee06

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

eaee06

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

eaee06

"finalizing" at unlock door.

eaee06

Secondly, whenever you employ fully fledged

eaee06

file system, I/O requests get inevitably fragmented.

eaee06

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

eaee06

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

eaee06

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

eaee06

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

eaee06

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

eaee06

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

eaee06

order to optimize the process certain caching algorithm is implemented

eaee06

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

eaee06

situations. And so in such unfortunate situations the drive apparently

eaee06

stops processing I/O requests returning "COMMAND SEQUENCE ERROR

eaee06

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

eaee06

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

eaee06

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

eaee06

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

eaee06

flow.

eaee06

Unfortunately the above paragraph doesn't

eaee06

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

eaee06

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

eaee06

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

eaee06

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

eaee06

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

eaee06

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

eaee06

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

eaee06

[but not the same] behaviour under apparently extremely rare

eaee06

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

eaee06

reportedly disappears with firmware upgrade...

eaee06

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

eaee06

most vendors, seem to not bother about complying with

eaee06

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

eaee06

granularity" part in particular. Instead they apparently expect

eaee06

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

eaee06

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

eaee06

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

eaee06

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

eaee06

it's the reality of marketplace:-(

eaee06

This one really beats me. Sometimes the unit

eaee06

simply stops writing signaling a vendor specific positioning error,

eaee06

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

eaee06

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

eaee06

requests so that they are not sequential anymore, "FLUSH

eaee06

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

eaee06

"underrun" condition background formatting kicks off and has

eaee06

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

eaee06

the unit is supposed to handle temporary data stream outages

eaee06

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

eaee06

complement growisofs command line with [undocumented]

eaee06

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

eaee06

This option eliminates request reorders and minimizes possibility for

eaee06

"underrun" condition (by releasing the pressure off VM

eaee06

subsystem).

eaee06

The original idea was to implement DVD+RW support in

eaee06

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

eaee06

"writeable" flag controlling the ability to issue WRITE

eaee06

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

eaee06

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

eaee06

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

eaee06

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

eaee06

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

eaee06

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

eaee06

Unfortunately it was not possible to implement it

eaee06

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

eaee06

modification was required to sense the media before decision about

eaee06

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

eaee06

morphing their behaviour after currently mounted media and it's

eaee06

essential to identify newly inserted media.

eaee06

Special comment about "what a dirty

eaee06

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

eaee06

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

eaee06

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

eaee06

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

eaee06

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

eaee06

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

eaee06

unused bits from the "quiet" argument instead of modifying

eaee06

all the calls (too boring).

eaee06

But even if time-out value passed down to kernel

eaee06

(with either CDROM_SEND_PACKET or SG_IO ioctl) is taken into

eaee06

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

eaee06

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

eaee06

CDROM_SEND_PACKET, but following the common sense most programmers

eaee06

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

eaee06

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

eaee06

in turn is

eaee06

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

eaee06

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

eaee06

treats these values as "jiffies," which is a

eaee06

platform-dependent value representing time elapsed between timer

eaee06

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

eaee06

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

eaee06

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

eaee06

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

eaee06

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

eaee06

nor scale timeouts

eaee06

accordingly in respect to the legacy value of 10ms.

eaee06

There is another kernel "deficiency" I ran

eaee06

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

eaee06

The drive provides background formatting progress status, but

eaee06

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

eaee06

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

eaee06

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

eaee06

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

eaee06

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

eaee06

As you might have noticed the time-out value for

eaee06

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

eaee06

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

eaee06

when reformatting used media. Formatting of the blank

eaee06

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

eaee06

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

eaee06

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

eaee06

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

eaee06

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

eaee06

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

eaee06

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

eaee06

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

eaee06

manufacturing and want formatted capacity to reflect data set size.

eaee06

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

eaee06

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

eaee06

"finalize" the media.

eaee06

-->

eaee06

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

eaee06

Acard SCSI to

eaee06

IDE bridges.

eaee06

What does

eaee06

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

eaee06

stand for? Originally this paragraph started as following:

eaee06

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

eaee06

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

eaee06

information modulated into it. This makes it possible to resume

eaee06

interrupted [or deliberately suspended] burning process with accuracy

eaee06

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

eaee06

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

eaee06

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

eaee06

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

eaee06

Now given that both provided and tolerated inaccuracies are

eaee06

proportional to respectively writing and reading velocities there

eaee06

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

eaee06

buffer underrun will be universally playable.

eaee06

Well, it turned out that I was wrong about one

eaee06

thing.

eaee06

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

eaee06

groove also provides for adequately accurate recovery from

eaee06

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

eaee06

but accurate enough for splices to be playable in virtually any

eaee06

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

eaee06

specificaton apparently insists that you choose between

eaee06

buffer underrun protection and

eaee06

full DVD-ROM/-Video compatibility.

eaee06

The specification asserts that the latter is

eaee06

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

eaee06

was maintained uninterrupted throughout whole recording. Once again.

eaee06

Even though most vendors implement lossless linking in DAO

eaee06

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

eaee06

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

eaee06

problem is that "offended" sectors are denoted with certain

eaee06

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

eaee06

are supposed to be "corrected away" by ECC

eaee06

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

eaee06

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

eaee06

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

eaee06

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

eaee06

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

eaee06

[unconditional] buffer underrun protection.

eaee06

As already mentioned, DVD+ groove has

eaee06

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

eaee06

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

eaee06

arbitrary order, even to virgin surface and practically instantly

eaee06

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

eaee06

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

eaee06

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

eaee06

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

eaee06

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

eaee06

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

eaee06

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

eaee06

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

eaee06

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

eaee06

suspended at any time without any side effects. Consider following

eaee06

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

eaee06

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

eaee06

retrieve previously recorded data. This would naturally require

eaee06

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

eaee06

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

eaee06

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

eaee06

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

eaee06

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

eaee06

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

eaee06

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

eaee06

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

eaee06

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

eaee06

is instant regardless media state.

eaee06

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

eaee06

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

eaee06

themselves. Apparently a couple of "guiding" words are

eaee06

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

eaee06

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

eaee06

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

eaee06

recordings are children's game...

eaee06

Sometimes DVD+RW/+R recording strategy is referred

eaee06

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

eaee06

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

eaee06

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

eaee06

packets/extents are still denoted with certain linking information

eaee06

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

eaee06

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

eaee06

Data Zone, does not contain any linking information and is

eaee06

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

eaee06

mode (or DVD-ROM for that matter).

eaee06

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

eaee06

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

eaee06

it quite resistant to dust, scratches, etc.

eaee06

Now we can also discuss differences between

eaee06

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

eaee06

arbitrary layer break positioning yet maintaining contiguous logical

eaee06

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

eaee06

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

eaee06

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

eaee06

other hand implies unconditionally disjoint logical block addressing

eaee06

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

eaee06

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

eaee06

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

eaee06

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

eaee06

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

eaee06

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

eaee06

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

eaee06

Unlike DVD+plus that is.

eaee06

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

eaee06

<FONT SIZE="-1">According to

eaee06

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

eaee06

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

eaee06

buffer under-run occurs, the logical unit shall stop

eaee06

writing immediately and the logical unit shall start

eaee06

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

eaee06

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

eaee06

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

eaee06

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

eaee06

implementation being discussed here.</FONT>

eaee06

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

eaee06

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

eaee06

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

eaee06

playability.</FONT>

eaee06

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

eaee06

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

eaee06

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

eaee06

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

eaee06

back.</FONT>

eaee06

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

eaee06

</BODY>

eaee06

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