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

rpms / dvd+rw-tools

Blame SOURCES/index.html

Blob History Raw

<HTML>

97eda4

<HEAD>

97eda4

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

97eda4

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

97eda4

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

97eda4

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

97eda4

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

97eda4

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

97eda4

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

97eda4

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

97eda4

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

97eda4

			       multisession, growisofs">

97eda4

				  user-land utilities and optional Linux

97eda4

				  kernel patch">

97eda4

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

97eda4

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

97eda4

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

97eda4

</HEAD>

97eda4

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

97eda4

Blu-ray Disc/

97eda4

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

97eda4

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

97eda4

by <appro@fy.chalmers.se>,

97eda4

September 2006

97eda4

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

97eda4

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

97eda4

Q.	What is this page (not) about?

97eda4

A.<SUP> </SUP>

97eda4

	Maybe to your disappointment it is not about

97eda4

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

97eda4

	computer storage applications of Blu-ray Disc and

97eda4

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

97eda4

	exchange... The downloadable files are an optional

97eda4

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

97eda4

	couple of user-land utilities dubbed as <NOBR>

97eda4

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

97eda4

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

97eda4

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

97eda4

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

97eda4

	is "molded" in an ordinary data file system and

97eda4

	therefore no explicit support by the burning program is

97eda4

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

97eda4

	content preparation which is beyond the scope of this

97eda4

	page.</FONT>

97eda4

Q.	Kernel patch? This sounds too complicated

97eda4

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

97eda4

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

97eda4

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

97eda4

	without explicit kernel support. So if they

97eda4

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

97eda4

	patching the kernel is by all means optional. As

97eda4

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

97eda4

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

97eda4

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

97eda4

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

97eda4

	7.3 Release Notes say). On additional note Linux kernel

97eda4

	version 2.6>=10 is equipped with

97eda4

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

97eda4

	writing driver which supports even DVD rewritable media,

97eda4

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

97eda4

Q.	What is the kernel patch good for then?

97eda4

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

97eda4

	write access media and therefore is suitable for housing of an

97eda4

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

97eda4

	and this alone, qualifies DVD+RW support for kernel

97eda4

	implementation. However, I have to recommend to

97eda4

	deploy it with caution, see tutorial

97eda4

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

97eda4

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

97eda4

	moment of this writing apparenly only 2nd generation

97eda4

	Ricoh-based units (see

97eda4

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

97eda4

	generation listings) equipped with later firmware can sustain

97eda4

	I/O fragmentation (see Technical Ramblings below for further

97eda4

	details) and perform reliably.

97eda4

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

97eda4

A.	As implied/already mentioned - to master the

97eda4

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

97eda4

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

97eda4

	tutorial below, but figured that couple of words about the

97eda4

	[original] design ideas behind growisofs, the principal

97eda4

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

97eda4

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

97eda4

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

97eda4

	likely want to access the data on an arbitrary computer.

97eda4

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

97eda4

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

97eda4

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

97eda4

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

97eda4

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

97eda4

	Well, yes, unless you employ growisofs! Growisofs

97eda4

	provides the way to both lay down and grow an ISO9660

97eda4

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

97eda4

	image to) all supported optical media.

97eda4

Q.	But if they support  both + and - recording

97eda4

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

97eda4

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

97eda4

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

97eda4

	vast majority of DVD burners that are being introduced to the

97eda4

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

97eda4

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

97eda4

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

97eda4

	"seamless" multisessioning, not as reference to some

97eda4

	particular format:-)

97eda4

Q.	Do I still need

97eda4

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

97eda4

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

97eda4

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

97eda4

	actual ISO9660 file system layout. Secondly, the DVD burners

97eda4

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

97eda4

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

97eda4

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

97eda4

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

97eda4

	dvd+rw-tools with it/them?

97eda4

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

97eda4

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

97eda4

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

97eda4

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

97eda4

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

97eda4

	dvd+rw-tools provide experimental support even for

97eda4

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

97eda4

	dedicated page for further details.

97eda4

-->

97eda4

Q.	Does it work with my recorder unit?

97eda4

A.	If your unit is

97eda4

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

97eda4

	then the answer is "most likely it

97eda4

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

97eda4

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

97eda4

	unconditionally "most likely."

97eda4

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

97eda4

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

97eda4

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

97eda4

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

97eda4

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

97eda4

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

97eda4

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

97eda4

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

97eda4

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

97eda4

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

97eda4

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

97eda4

	the least all-mighty

97eda4

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

97eda4

Q.	Is there a GUI front-end available for

97eda4

	dvd+rw-tools?

97eda4

A.	K3b, version 0.10

97eda4

	and later, and

97eda4

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

97eda4

	version 0.5.1 and later, are both hiding growisofs behind their

97eda4

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

97eda4

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

97eda4

	effort and GUI users should turn elsewhere for end-user

97eda4

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

97eda4

	GUI frontends...

97eda4

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

97eda4

A.	Version 5.4 adds support for

97eda4

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

97eda4

	Version 5.6 adds support for Solaris 2.x

97eda4

	SIZE=-1>[commercial licensing

97eda4

	terms for distribution on Solaris are to be settled with

97eda4

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

97eda4

	Version 5.8 features

97eda4

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

97eda4

	port contributed by Matthew Dillon, FreeBSD Development Team

97eda4

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

97eda4

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

97eda4

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

97eda4

	5.19, Win32 one - in 6.0,

97eda4

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

97eda4

¡

97eda4

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

97eda4

	separately available [and unless stated otherwise], do use

97eda4

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

97eda4

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

97eda4

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

97eda4

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

97eda4

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

97eda4

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

97eda4

	you might have to mount

97eda4

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

97eda4

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

97eda4

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

97eda4

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

97eda4

	undergone HP quality assurance testing

97eda4

	and is delivered on HP

97eda4

	software depot.</FONT>

97eda4

Foreword

97eda4

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

97eda4

turn to <

97eda4

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

97eda4

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

97eda4

to be subscribed to post

97eda4

a problem report. List archives can be found at both

97eda4

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

97eda4

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

97eda4

When submitting report, provide versioning information, exact

97eda4

command line, exact output generated by the program and

97eda4

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

97eda4

resulting recording. Do check couple of last

97eda4

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

97eda4

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

97eda4

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

97eda4

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

97eda4

attentively...

97eda4

Special thanks for hardware donations [in

97eda4

chronological order]:

97eda4

ALT="Inserve Technology" BORDER=0>

97eda4

ALT="HP" BORDER=0>

97eda4

ALT="LinuxFund" BORDER=0>

97eda4

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

97eda4

Tutorial

97eda4


If your burner unit is managed by some

97eda4

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

97eda4

automounting/autoplaying facility, such as autofs, supermount,

97eda4

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

97eda4

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

97eda4

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

97eda4

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

97eda4

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

97eda4

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

97eda4

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

97eda4

recordings.

97eda4

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

97eda4

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

97eda4

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

97eda4

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

97eda4

under their control.</FONT>

97eda4


Remember to consult

97eda4

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

97eda4

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

97eda4

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

97eda4

enough to bring it up already here:-)

97eda4


If you have an IDE unit and run 2.4.x

97eda4

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

97eda4

emulation layer by either:

97eda4

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

97eda4

argument to kernel;

97eda4

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

97eda4

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

97eda4

pre-install sg modprobe ide-scsi

97eda4

pre-install sr_mod modprobe ide-scsi

97eda4

pre-install ide-scsi modprobe ide-cd

97eda4

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

97eda4

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

97eda4

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

97eda4

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

97eda4

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

97eda4

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

97eda4

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

97eda4

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

97eda4

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

97eda4

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

97eda4

some IDE chipsets...</FONT>

97eda4


If you have an external unit, just get

97eda4

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

97eda4

whatsoever with USB or

97eda4

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

97eda4

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

97eda4

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

97eda4

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

97eda4

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

97eda4

connected drives were reported to be working fine since eternity.

97eda4

Firewire connected drives in turn were reported to fail miserably under

97eda4

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

97eda4

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

97eda4

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

97eda4

work with this and later kernels.

97eda4


If you're running 2.4.19 or .20, consider

97eda4

applying this drivers/scsi/sg.c patch.

97eda4

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

97eda4

"do" for the following reasons:

97eda4

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

97eda4

interface), cdrecord [potentially] is;

97eda4

I however haven't actually experienced the problem with cdrecord

97eda4

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

97eda4

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

97eda4

failed miserably on me;

97eda4

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

97eda4

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

97eda4

where "generic" SCSI interface can be bypassed by issuing

97eda4

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

97eda4

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

97eda4

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

97eda4

patches #1 and

97eda4

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

97eda4

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

97eda4

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

97eda4

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

97eda4

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

97eda4

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

97eda4

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

97eda4

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

97eda4

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

97eda4

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

97eda4

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

97eda4

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

97eda4

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

97eda4

"supported" recommendation is to just stay away from this

97eda4

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

97eda4

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

97eda4

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

97eda4

utility works only with limited number of units, installation procedure

97eda4

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

97eda4

this security sensitive choice to the end-user.

97eda4


Download, unpack and compile the

97eda4

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

97eda4

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

97eda4

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

97eda4

source code files found in the download catalog

97eda4

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

97eda4

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

97eda4

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

97eda4

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

97eda4

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

97eda4

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

97eda4

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

97eda4

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

97eda4

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

97eda4

CDROM_SEND_PACKET ioctl deployed by dvd+rw-tools.

97eda4


As new media products and brands are being

97eda4

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

97eda4

periodically check for firmware updates. For elder units

97eda4

firmware update might even be an absolute requirement for using

97eda4

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

97eda4

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

97eda4

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

97eda4

files in

97eda4

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

97eda4

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

97eda4


Formatting the BD and DVD+RW media.

97eda4

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

97eda4

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

97eda4

formatted. As of version 5.10 growisofs detects blanks and applies

97eda4

initial formatting procedure automatically. Otherwise same effect can

97eda4

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

97eda4

argument to dvd+rw-format. Well,

97eda4

in BD case it does offer more flexibility than

97eda4

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

97eda4

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

97eda4

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

97eda4

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

97eda4

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

97eda4

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

97eda4

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

97eda4

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

97eda4

so is one of BD.

97eda4

It was observed that excessive reformats can render

97eda4

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

97eda4

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

97eda4

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

97eda4

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

97eda4

Note that re-formatting procedure does not

97eda4

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

97eda4

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

97eda4

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

97eda4

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

97eda4

re-formatting is required.

97eda4

DVD+R media does not require any formatting

97eda4

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

97eda4

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

97eda4

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

97eda4


Burning with

97eda4

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

97eda4

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

97eda4

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

97eda4

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

97eda4

consult mkisofs manual page and

97eda4

accompanying reference documentation (including multisession related

97eda4

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

97eda4

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

97eda4

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

97eda4

are:

97eda4

you may not use -o option;

97eda4

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

97eda4

for you;

97eda4

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

97eda4

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

97eda4

Otherwise everything that applies to

97eda4

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

97eda4

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

97eda4

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

97eda4

them, e.g.:

97eda4

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

97eda4

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

97eda4

Oh! Do make sure you have at least mkisofs

97eda4

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

97eda4

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

97eda4

other words consider deploying growisofs for incremental

97eda4

multisession backups, then you shall find

97eda4

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

97eda4

mkisofs <FONT COLOR="red">2

97eda4

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

97eda4

The idea and implementation by

97eda4

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

97eda4

"graft" recording sessions as separate directories. Each

97eda4

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

97eda4

references to previously backed up ones, which facilitates

97eda4

comparison between increments as well as fine-graded restore.

97eda4

Number of users asked about opposite to

97eda4

multisessioning: multivolume support. Being essentially a recording

97eda4

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

97eda4

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

97eda4

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

97eda4

shunt. But back to

97eda4

growisofs...

97eda4

In addition to intuitive -Z interpretation,

97eda4

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

97eda4

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

97eda4

"magic" command is:

97eda4

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

97eda4

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

97eda4

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

97eda4

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

97eda4

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

97eda4

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

97eda4

arbitrary program, you can use:

97eda4

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

97eda4

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

97eda4

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

97eda4

option<TT>:-)</TT>

97eda4

Apparently media needs to be manually reloaded [ejected and pushed

97eda4

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

97eda4

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

97eda4

--->

97eda4

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

97eda4

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

97eda4

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

97eda4

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

97eda4

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

97eda4

capable to access data added at different occasions.

97eda4

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

97eda4

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

97eda4

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

97eda4

work it around by reloading corresponding driver, most likely

97eda4

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

97eda4

Linux kernel 2.6<

97eda4

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

97eda4

users might experience

97eda4

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

97eda4

mounting multisession media with last session starting beyond

97eda4

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

97eda4

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

97eda4

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

97eda4

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

97eda4

mkisofs from cdrtools-2.0

97eda4

or later or apply this patch.

97eda4

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

97eda4

Dual Layer recordings, growisofs applies yet another limitation,

97eda4

purely artificial. Taking into consideration Double Layer media prices

97eda4

growisofs is programmed to refuse to perform unappendable

97eda4

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

97eda4

to use single layer media instead.

97eda4

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

97eda4

discussed on the -RW companion page. Once

97eda4

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

97eda4

recordings come out unappendable and can not be grown.

97eda4

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

97eda4

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

97eda4

translated to "real" GB, single layer

97eda4

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

97eda4

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

97eda4

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

97eda4

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

97eda4

responsibility to make sure "overburn" condition is not

97eda4

raised. As of version 5.2 growisofs performs the necessary checks

97eda4

for you and refuses to start recording if "overburn"

97eda4

condition appears to be unavoidable. This behaviour can be overridden

97eda4

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

97eda4


If you're satisfied with growisofs, then you

97eda4

should just proceed to the next chapter

97eda4

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

97eda4

you haven't stopped reading beyond this line,

97eda4

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

97eda4

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

97eda4

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

97eda4

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

97eda4

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

97eda4

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

97eda4

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

97eda4

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

97eda4

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

97eda4

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

97eda4

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

97eda4

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

97eda4

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

97eda4

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

97eda4

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

97eda4

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

97eda4

your original Linux source code ditribution.-->

97eda4

Linux 2.6 DVD+RW kernel support is planned in

97eda4

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

97eda4

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

97eda4

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

97eda4

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

97eda4

Philips DVDRW416K or BenQ DW400A do not actually implement

97eda4

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

97eda4

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

97eda4

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

97eda4

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

97eda4

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

97eda4

software in opposite to Mt.Rainier firmware).

97eda4

Even though kernel now

97eda4

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

97eda4

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

97eda4

tempting it might appear.

97eda4

As you might know DVD+RW media can sustain only

97eda4

around 1000 overwrites. The thing about fully fledged file systems

97eda4

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

97eda4

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

97eda4

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

97eda4

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

97eda4

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

97eda4

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

97eda4

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

97eda4

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

97eda4

year [

97eda4

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

97eda4

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

97eda4

[in firmware, a.k.a.

97eda4

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

97eda4

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

97eda4

file system driver should definitely refrain from modifying the

97eda4

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

97eda4

last mount. Given the development status of

97eda4

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

97eda4

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

97eda4

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

97eda4

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

97eda4

UDF write support is unfortunately disabled and you might have to

97eda4

reconfigure the kernel and rebuild modules. Alternatively [my preferred

97eda4

option actually] fetch the code at

97eda4

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

97eda4

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

97eda4

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

97eda4

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

97eda4

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

97eda4

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

97eda4

by UDF maintainer, Ben Fennema.

97eda4


Performance optimization. This paragraph

97eda4

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

97eda4

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

97eda4

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

97eda4

so, as common block device layer completely reorganizes the

97eda4

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

97eda4

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

97eda4

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

97eda4

through block buffer cache. To minimize the pressure and improve

97eda4

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

97eda4

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

97eda4

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

97eda4

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

97eda4

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

97eda4

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

97eda4

out, consider

97eda4

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

97eda4

"hacklet"...

97eda4

Compatibility: caveat lector

97eda4

This paragraph discusses "DVD-ROM

97eda4

compatibility," or playability of already recorded media in legacy

97eda4

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

97eda4

start or fulfill recording because of poor media support by burner

97eda4

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

97eda4

supported media and/or to the

97eda4

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

97eda4

experience.

97eda4

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

97eda4

calibrate their mechanics every time the media is loaded by sliding

97eda4

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

97eda4

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

97eda4

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

97eda4

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

97eda4

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

97eda4

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

97eda4

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

97eda4

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

97eda4

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

97eda4

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

97eda4

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

97eda4

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

97eda4

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

97eda4

to

97eda4

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

97eda4

COLOR="red">N</FONT>

97eda4

which relocates the lead-out next to outermost

97eda4

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

97eda4

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

97eda4

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

97eda4

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

97eda4

lead-out.-->

97eda4

Then non-finalized DVD+R and Sequential

97eda4

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

97eda4

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

97eda4

remaining space for immediate compatibility, just fill the media

97eda4

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

97eda4

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

97eda4

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

97eda4

the real lead-out directly after the first session.

97eda4

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

97eda4

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

97eda4

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

97eda4

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

97eda4

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

97eda4

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

97eda4

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

97eda4

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

97eda4

</FONT>

97eda4

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

97eda4

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

97eda4

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

97eda4

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

97eda4

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

97eda4

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

97eda4

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

97eda4

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

97eda4

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

97eda4

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

97eda4

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

97eda4

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

97eda4

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

97eda4

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

97eda4

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

97eda4

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

97eda4

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

97eda4

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

97eda4

Then we have logical format compatibility

97eda4

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

97eda4

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

97eda4

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

97eda4

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

97eda4

format specifications don't explicitly say that unrecognized format

97eda4

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

97eda4

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

97eda4

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

97eda4

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

97eda4

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

97eda4

apparently by "traditional" DVD+RW vendors and not

97eda4

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

97eda4

secret vendor-specific command

97eda4

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

97eda4

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

97eda4

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

97eda4

COLOR="red">N</FONT>

97eda4

Once again. Not all vendors support this and you

97eda4

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

97eda4

It's naturally not possible to manipulate the

97eda4

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

97eda4

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

97eda4

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

97eda4

going to be branded by programming the drive in advance:

97eda4

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

97eda4

COLOR="red">N</FONT>

97eda4

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

97eda4

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

97eda4

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

97eda4

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

97eda4

Bitsettings" article at dvdplusrw.org.

97eda4

There [potentially] are other logical

97eda4

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

97eda4

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

97eda4

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

97eda4

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

97eda4

Recognition of other incompatibilities would require cooperation from

97eda4

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

97eda4

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

97eda4

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

97eda4

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

97eda4

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

97eda4

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

97eda4

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

97eda4

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

97eda4

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

97eda4

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

97eda4

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

97eda4

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

97eda4

development initiative.</FONT>

97eda4

Finally there is a physical incompatibility issue.

97eda4

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

97eda4

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

97eda4

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

97eda4

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

97eda4

distinguish physical from logical format incompatibility, which I find

97eda4

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

97eda4

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

97eda4

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

97eda4

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

97eda4

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

97eda4

that if player makes assumptions about linear pit density based on

97eda4

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

97eda4

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

97eda4

player...

97eda4

Technical Ramblings

97eda4

ALIGN="RIGHT">

97eda4

As for multisession ISO9660 [DVD]

97eda4

recordings! Unfortunately, Linux ISOFS implementation had certain

97eda4

deficiency which limits interoperability of such recordings. In order

97eda4

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

97eda4

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

97eda4

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

97eda4

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

97eda4

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

97eda4

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

97eda4

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

97eda4

collects all the directories in the beginning of any particular session

97eda4

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

97eda4

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

97eda4

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

97eda4

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

97eda4

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

97eda4

particular not in further sessions. Having noted that directory entries

97eda4

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

97eda4

it's perfectly possible to

97eda4

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

97eda4

maximum interoperability, you should not let any session

97eda4

start past 4GB minus space required for directory

97eda4

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

97eda4

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

97eda4

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

97eda4

pretty much arbitrary chosen large value, large for directory catalogs

97eda4

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

97eda4

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

97eda4

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

97eda4

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

97eda4

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

97eda4

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

97eda4

broader compatibility of final DVD recordings. This check is not

97eda4

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

97eda4

such user community would run something elder than 2.6.9 is considered

97eda4

diminishingly low.

97eda4

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

97eda4

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

97eda4

file in a file system</FONT>

97eda4

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

97eda4

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

97eda4

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

97eda4

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

97eda4

kernel developers only;-)</FONT>

97eda4

Why media reload is performed after every

97eda4

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

97eda4

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

97eda4

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

97eda4

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

97eda4

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

97eda4

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

97eda4

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

97eda4

unaware of growisofs activities, growisofs bypasses the block

97eda4

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

97eda4

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

97eda4

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

97eda4

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

97eda4

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

97eda4

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

97eda4

access beyond end of device."

97eda4

What does [kernel] "DVD+RW support"

97eda4

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

97eda4

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

97eda4

"CLOSE TRACK/SESSION (5Bh)"

97eda4

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

97eda4

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

97eda4

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

97eda4

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

97eda4

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

97eda4

"finalizing" at unlock door.

97eda4

Secondly, whenever you employ fully fledged

97eda4

file system, I/O requests get inevitably fragmented.

97eda4

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

97eda4

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

97eda4

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

97eda4

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

97eda4

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

97eda4

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

97eda4

order to optimize the process certain caching algorithm is implemented

97eda4

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

97eda4

situations. And so in such unfortunate situations the drive apparently

97eda4

stops processing I/O requests returning "COMMAND SEQUENCE ERROR

97eda4

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

97eda4

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

97eda4

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

97eda4

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

97eda4

flow.

97eda4

Unfortunately the above paragraph doesn't

97eda4

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

97eda4

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

97eda4

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

97eda4

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

97eda4

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

97eda4

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

97eda4

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

97eda4

[but not the same] behaviour under apparently extremely rare

97eda4

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

97eda4

reportedly disappears with firmware upgrade...

97eda4

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

97eda4

most vendors, seem to not bother about complying with

97eda4

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

97eda4

granularity" part in particular. Instead they apparently expect

97eda4

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

97eda4

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

97eda4

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

97eda4

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

97eda4

it's the reality of marketplace:-(

97eda4

This one really beats me. Sometimes the unit

97eda4

simply stops writing signaling a vendor specific positioning error,

97eda4

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

97eda4

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

97eda4

requests so that they are not sequential anymore, "FLUSH

97eda4

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

97eda4

"underrun" condition background formatting kicks off and has

97eda4

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

97eda4

the unit is supposed to handle temporary data stream outages

97eda4

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

97eda4

complement growisofs command line with [undocumented]

97eda4

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

97eda4

This option eliminates request reorders and minimizes possibility for

97eda4

"underrun" condition (by releasing the pressure off VM

97eda4

subsystem).

97eda4

The original idea was to implement DVD+RW support in

97eda4

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

97eda4

"writeable" flag controlling the ability to issue WRITE

97eda4

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

97eda4

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

97eda4

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

97eda4

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

97eda4

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

97eda4

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

97eda4

Unfortunately it was not possible to implement it

97eda4

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

97eda4

modification was required to sense the media before decision about

97eda4

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

97eda4

morphing their behaviour after currently mounted media and it's

97eda4

essential to identify newly inserted media.

97eda4

Special comment about "what a dirty

97eda4

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

97eda4

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

97eda4

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

97eda4

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

97eda4

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

97eda4

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

97eda4

unused bits from the "quiet" argument instead of modifying

97eda4

all the calls (too boring).

97eda4

But even if time-out value passed down to kernel

97eda4

(with either CDROM_SEND_PACKET or SG_IO ioctl) is taken into

97eda4

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

97eda4

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

97eda4

CDROM_SEND_PACKET, but following the common sense most programmers

97eda4

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

97eda4

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

97eda4

in turn is

97eda4

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

97eda4

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

97eda4

treats these values as "jiffies," which is a

97eda4

platform-dependent value representing time elapsed between timer

97eda4

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

97eda4

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

97eda4

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

97eda4

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

97eda4

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

97eda4

nor scale timeouts

97eda4

accordingly in respect to the legacy value of 10ms.

97eda4

There is another kernel "deficiency" I ran

97eda4

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

97eda4

The drive provides background formatting progress status, but

97eda4

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

97eda4

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

97eda4

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

97eda4

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

97eda4

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

97eda4

As you might have noticed the time-out value for

97eda4

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

97eda4

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

97eda4

when reformatting used media. Formatting of the blank

97eda4

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

97eda4

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

97eda4

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

97eda4

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

97eda4

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

97eda4

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

97eda4

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

97eda4

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

97eda4

manufacturing and want formatted capacity to reflect data set size.

97eda4

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

97eda4

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

97eda4

"finalize" the media.

97eda4

-->

97eda4

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

97eda4

Acard SCSI to

97eda4

IDE bridges.

97eda4

What does

97eda4

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

97eda4

stand for? Originally this paragraph started as following:

97eda4

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

97eda4

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

97eda4

information modulated into it. This makes it possible to resume

97eda4

interrupted [or deliberately suspended] burning process with accuracy

97eda4

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

97eda4

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

97eda4

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

97eda4

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

97eda4

Now given that both provided and tolerated inaccuracies are

97eda4

proportional to respectively writing and reading velocities there

97eda4

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

97eda4

buffer underrun will be universally playable.

97eda4

Well, it turned out that I was wrong about one

97eda4

thing.

97eda4

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

97eda4

groove also provides for adequately accurate recovery from

97eda4

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

97eda4

but accurate enough for splices to be playable in virtually any

97eda4

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

97eda4

specificaton apparently insists that you choose between

97eda4

buffer underrun protection and

97eda4

full DVD-ROM/-Video compatibility.

97eda4

The specification asserts that the latter is

97eda4

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

97eda4

was maintained uninterrupted throughout whole recording. Once again.

97eda4

Even though most vendors implement lossless linking in DAO

97eda4

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

97eda4

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

97eda4

problem is that "offended" sectors are denoted with certain

97eda4

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

97eda4

are supposed to be "corrected away" by ECC

97eda4

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

97eda4

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

97eda4

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

97eda4

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

97eda4

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

97eda4

[unconditional] buffer underrun protection.

97eda4

As already mentioned, DVD+ groove has

97eda4

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

97eda4

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

97eda4

arbitrary order, even to virgin surface and practically instantly

97eda4

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

97eda4

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

97eda4

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

97eda4

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

97eda4

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

97eda4

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

97eda4

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

97eda4

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

97eda4

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

97eda4

suspended at any time without any side effects. Consider following

97eda4

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

97eda4

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

97eda4

retrieve previously recorded data. This would naturally require

97eda4

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

97eda4

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

97eda4

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

97eda4

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

97eda4

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

97eda4

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

97eda4

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

97eda4

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

97eda4

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

97eda4

is instant regardless media state.

97eda4

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

97eda4

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

97eda4

themselves. Apparently a couple of "guiding" words are

97eda4

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

97eda4

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

97eda4

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

97eda4

recordings are children's game...

97eda4

Sometimes DVD+RW/+R recording strategy is referred

97eda4

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

97eda4

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

97eda4

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

97eda4

packets/extents are still denoted with certain linking information

97eda4

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

97eda4

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

97eda4

Data Zone, does not contain any linking information and is

97eda4

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

97eda4

mode (or DVD-ROM for that matter).

97eda4

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

97eda4

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

97eda4

it quite resistant to dust, scratches, etc.

97eda4

Now we can also discuss differences between

97eda4

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

97eda4

arbitrary layer break positioning yet maintaining contiguous logical

97eda4

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

97eda4

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

97eda4

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

97eda4

other hand implies unconditionally disjoint logical block addressing

97eda4

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

97eda4

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

97eda4

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

97eda4

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

97eda4

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

97eda4

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

97eda4

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

97eda4

Unlike DVD+plus that is.

97eda4

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

97eda4

<FONT SIZE="-1">According to

97eda4

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

97eda4

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

97eda4

buffer under-run occurs, the logical unit shall stop

97eda4

writing immediately and the logical unit shall start

97eda4

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

97eda4

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

97eda4

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

97eda4

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

97eda4

implementation being discussed here.</FONT>

97eda4

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

97eda4

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

97eda4

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

97eda4

playability.</FONT>

97eda4

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

97eda4

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

97eda4

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

97eda4

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

97eda4

back.</FONT>

97eda4

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

97eda4

</BODY>

97eda4

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