Tree - rpms/dvd+rw-tools - src.fedoraproject.org

rpms / dvd+rw-tools

Blame index.html

Blob History Raw

<HTML>

955f950

<HEAD>

955f950

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

e8532ab

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

e8532ab

955f950

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

e8532ab

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

e8532ab

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

955f950

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

e8532ab

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

955f950

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

955f950

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

e8532ab

			       multisession, growisofs">

e8532ab

955f950

				  user-land utilities and optional Linux

955f950

				  kernel patch">

955f950

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

955f950

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

955f950

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

955f950

</HEAD>

955f950

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

955f950

e8532ab

Blu-ray Disc/

e8532ab

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

955f950

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

955f950

by <appro@fy.chalmers.se>,

e8532ab

September 2006

955f950

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

955f950

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

955f950

Q.	What is this page (not) about?

955f950

A.<SUP> </SUP>

955f950

	Maybe to your disappointment it is not about

955f950

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

e8532ab

	computer storage applications of Blu-ray Disc and

e8532ab

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

e8532ab

	exchange... The downloadable files are an optional

955f950

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

955f950

	couple of user-land utilities dubbed as <NOBR>

955f950

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

955f950

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

955f950

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

955f950

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

955f950

	is "molded" in an ordinary data file system and

955f950

	therefore no explicit support by the burning program is

955f950

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

955f950

	content preparation which is beyond the scope of this

955f950

	page.</FONT>

955f950

Q.	Kernel patch? This sounds too complicated

e8532ab

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

955f950

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

e8532ab

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

955f950

	without explicit kernel support. So if they

955f950

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

955f950

	patching the kernel is by all means optional. As

e8532ab

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

e8532ab

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

e8532ab

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

955f950

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

e8532ab

	7.3 Release Notes say). On additional note Linux kernel

e8532ab

	version 2.6>=10 is equipped with

e8532ab

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

e8532ab

	writing driver which supports even DVD rewritable media,

e8532ab

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

955f950

Q.	What is the kernel patch good for then?

955f950

e8532ab

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

e8532ab

	write access media and therefore is suitable for housing of an

e8532ab

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

e8532ab

	and this alone, qualifies DVD+RW support for kernel

e8532ab

	implementation. However, I have to recommend to

e8532ab

	deploy it with caution, see tutorial

e8532ab

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

e8532ab

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

e8532ab

	moment of this writing apparenly only 2nd generation

e8532ab

	Ricoh-based units (see

955f950

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

955f950

	generation listings) equipped with later firmware can sustain

955f950

	I/O fragmentation (see Technical Ramblings below for further

955f950

	details) and perform reliably.

955f950

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

955f950

e8532ab

A.	As implied/already mentioned - to master the

e8532ab

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

e8532ab

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

e8532ab

	tutorial below, but figured that couple of words about the

e8532ab

	[original] design ideas behind growisofs, the principal

e8532ab

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

e8532ab

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

e8532ab

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

955f950

	likely want to access the data on an arbitrary computer.

955f950

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

955f950

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

955f950

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

955f950

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

955f950

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

955f950

	Well, yes, unless you employ growisofs! Growisofs

955f950

	provides the way to both lay down and grow an ISO9660

955f950

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

e8532ab

	image to) all supported optical media.

955f950

Q.	But if they support  both + and - recording

955f950

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

955f950

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

955f950

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

955f950

	vast majority of DVD burners that are being introduced to the

955f950

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

955f950

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

e8532ab

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

e8532ab

	"seamless" multisessioning, not as reference to some

955f950

	particular format:-)

955f950

Q.	Do I still need

e8532ab

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

955f950

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

955f950

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

955f950

	actual ISO9660 file system layout. Secondly, the DVD burners

955f950

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

955f950

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

955f950

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

955f950

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

955f950

	dvd+rw-tools with it/them?

955f950

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

955f950

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

955f950

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

955f950

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

955f950

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

955f950

	dvd+rw-tools provide experimental support even for

955f950

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

955f950

	dedicated page for further details.

955f950

-->

955f950

e8532ab

Q.	Does it work with my recorder unit?

955f950

A.	If your unit is

955f950

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

955f950

	then the answer is "most likely it

955f950

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

955f950

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

955f950

	unconditionally "most likely."

955f950

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

e8532ab

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

955f950

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

955f950

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

e8532ab

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

955f950

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

e8532ab

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

e8532ab

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

e8532ab

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

e8532ab

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

e8532ab

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

e8532ab

	the least all-mighty

e8532ab

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

955f950

Q.	Is there a GUI front-end available for

955f950

	dvd+rw-tools?

955f950

A.	K3b, version 0.10

955f950

	and later, and

955f950

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

955f950

	version 0.5.1 and later, are both hiding growisofs behind their

955f950

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

955f950

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

955f950

	effort and GUI users should turn elsewhere for end-user

955f950

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

955f950

	GUI frontends...

955f950

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

955f950

A.	Version 5.4 adds support for

955f950

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

955f950

	Version 5.6 adds support for Solaris 2.x

955f950

	SIZE=-1>[commercial licensing

955f950

	terms for distribution on Solaris are to be settled with

955f950

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

955f950

	Version 5.8 features

955f950

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

955f950

	port contributed by Matthew Dillon, FreeBSD Development Team

955f950

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

955f950

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

955f950

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

e8532ab

	5.19, Win32 one - in 6.0,

e8532ab

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

955f950

¡

955f950

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

955f950

	separately available [and unless stated otherwise], do use

955f950

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

955f950

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

955f950

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

955f950

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

955f950

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

955f950

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

955f950

	you might have to mount

955f950

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

955f950

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

955f950

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

955f950

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

955f950

	undergone HP quality assurance testing

955f950

	and is delivered on HP

955f950

	software depot.</FONT>

955f950

e8532ab

Foreword

955f950

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

955f950

turn to <

955f950

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

955f950

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

955f950

to be subscribed to post

955f950

a problem report. List archives can be found at both

955f950

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

955f950

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

955f950

When submitting report, provide versioning information, exact

955f950

command line, exact output generated by the program and

955f950

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

955f950

resulting recording. Do check couple of last

955f950

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

955f950

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

955f950

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

955f950

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

955f950

attentively...

955f950

Special thanks for hardware donations [in

955f950

chronological order]:

955f950

ALT="Inserve Technology" BORDER=0>

955f950

ALT="HP" BORDER=0>

955f950

ALT="LinuxFund" BORDER=0>

955f950

e8532ab

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

e8532ab

955f950

Tutorial

955f950


If your burner unit is managed by some

955f950

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

955f950

automounting/autoplaying facility, such as autofs, supermount,

955f950

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

955f950

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

955f950

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

955f950

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

955f950

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

955f950

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

955f950

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

955f950

recordings.

955f950

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

955f950

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

955f950

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

955f950

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

955f950

under their control.</FONT>

955f950


Remember to consult

955f950

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

955f950

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

955f950

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

955f950

enough to bring it up already here:-)

955f950


If you have an IDE unit and run 2.4.x

955f950

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

955f950

emulation layer by either:

955f950

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

955f950

argument to kernel;

955f950

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

955f950

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

955f950

pre-install sg modprobe ide-scsi

955f950

pre-install sr_mod modprobe ide-scsi

955f950

pre-install ide-scsi modprobe ide-cd

955f950

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

955f950

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

955f950

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

955f950

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

955f950

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

955f950

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

955f950

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

955f950

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

955f950

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

e8532ab

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

955f950

some IDE chipsets...</FONT>

955f950


If you have an external unit, just get

955f950

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

955f950

whatsoever with USB or

e8532ab

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

e8532ab

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

e8532ab

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

e8532ab

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

e8532ab

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

e8532ab

connected drives were reported to be working fine since eternity.

e8532ab

Firewire connected drives in turn were reported to fail miserably under

e8532ab

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

e8532ab

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

e8532ab

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

e8532ab

work with this and later kernels.

955f950


If you're running 2.4.19 or .20, consider

955f950

applying this drivers/scsi/sg.c patch.

955f950

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

955f950

"do" for the following reasons:

955f950

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

955f950

interface), cdrecord [potentially] is;

955f950

I however haven't actually experienced the problem with cdrecord

955f950

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

955f950

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

955f950

failed miserably on me;

955f950

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

955f950

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

955f950

where "generic" SCSI interface can be bypassed by issuing

955f950

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

955f950

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

955f950

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

955f950

patches #1 and

955f950

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

955f950

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

955f950

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

955f950

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

955f950

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

955f950

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

955f950

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

955f950

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

955f950

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

955f950

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

955f950

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

955f950

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

955f950

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

955f950

"supported" recommendation is to just stay away from this

955f950

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

955f950

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

955f950

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

955f950

utility works only with limited number of units, installation procedure

955f950

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

955f950

this security sensitive choice to the end-user.

955f950


Download, unpack and compile the

955f950

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

955f950

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

955f950

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

955f950

source code files found in the download catalog

955f950

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

955f950

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

955f950

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

955f950

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

955f950

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

955f950

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

955f950

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

955f950

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

955f950

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

955f950

CDROM_SEND_PACKET ioctl deployed by dvd+rw-tools.

955f950

e8532ab


As new media products and brands are being

955f950

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

e8532ab

periodically check for firmware updates. For elder units

e8532ab

firmware update might even be an absolute requirement for using

e8532ab

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

e8532ab

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

e8532ab

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

e8532ab

files in

955f950

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

955f950

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

955f950

e8532ab


Formatting the BD and DVD+RW media.

e8532ab

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

e8532ab

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

e8532ab

formatted. As of version 5.10 growisofs detects blanks and applies

e8532ab

initial formatting procedure automatically. Otherwise same effect can

e8532ab

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

e8532ab

argument to dvd+rw-format. Well,

e8532ab

in BD case it does offer more flexibility than

e8532ab

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

e8532ab

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

e8532ab

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

e8532ab

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

e8532ab

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

e8532ab

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

e8532ab

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

e8532ab

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

e8532ab

so is one of BD.

955f950

It was observed that excessive reformats can render

e8532ab

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

955f950

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

955f950

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

e8532ab

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

e8532ab

Note that re-formatting procedure does not

e8532ab

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

e8532ab

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

e8532ab

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

e8532ab

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

e8532ab

re-formatting is required.

955f950

e8532ab

955f950

DVD+R media does not require any formatting

955f950

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

955f950

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

e8532ab

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

955f950


Burning with

955f950

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

955f950

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

955f950

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

955f950

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

955f950

consult mkisofs manual page and

e8532ab

accompanying reference documentation (including multisession related

955f950

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

955f950

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

955f950

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

955f950

are:

955f950

you may not use -o option;

955f950

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

955f950

for you;

955f950

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

955f950

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

955f950

Otherwise everything that applies to

e8532ab

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

955f950

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

955f950

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

955f950

them, e.g.:

955f950

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

955f950

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

955f950

Oh! Do make sure you have at least mkisofs

955f950

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

955f950

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

955f950

other words consider deploying growisofs for incremental

e8532ab

multisession backups, then you shall find

955f950

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

955f950

mkisofs <FONT COLOR="red">2

955f950

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

955f950

The idea and implementation by

955f950

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

955f950

"graft" recording sessions as separate directories. Each

955f950

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

955f950

references to previously backed up ones, which facilitates

955f950

comparison between increments as well as fine-graded restore.

955f950

Number of users asked about opposite to

e8532ab

multisessioning: multivolume support. Being essentially a recording

955f950

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

955f950

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

e8532ab

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

e8532ab

shunt. But back to

e8532ab

growisofs...

955f950

In addition to intuitive -Z interpretation,

955f950

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

955f950

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

955f950

"magic" command is:

955f950

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

955f950

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

955f950

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

955f950

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

955f950

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

955f950

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

955f950

arbitrary program, you can use:

955f950

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

955f950

e8532ab

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

955f950

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

955f950

option<TT>:-)</TT>

955f950

Apparently media needs to be manually reloaded [ejected and pushed

955f950

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

955f950

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

955f950

--->

955f950

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

955f950

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

955f950

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

e8532ab

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

955f950

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

955f950

capable to access data added at different occasions.

955f950

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

955f950

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

955f950

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

955f950

work it around by reloading corresponding driver, most likely

955f950

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

955f950

e8532ab

Linux kernel 2.6<

e8532ab

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

e8532ab

users might experience

955f950

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

e8532ab

mounting multisession media with last session starting beyond

955f950

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

e8532ab

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

955f950

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

955f950

e8532ab

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

955f950

mkisofs from cdrtools-2.0

955f950

or later or apply this patch.

955f950

e8532ab

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

e8532ab

Dual Layer recordings, growisofs applies yet another limitation,

e8532ab

purely artificial. Taking into consideration Double Layer media prices

e8532ab

growisofs is programmed to refuse to perform unappendable

e8532ab

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

e8532ab

to use single layer media instead.

e8532ab

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

e8532ab

discussed on the -RW companion page. Once

e8532ab

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

e8532ab

recordings come out unappendable and can not be grown.

955f950

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

955f950

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

e8532ab

translated to "real" GB, single layer

e8532ab

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

e8532ab

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

955f950

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

955f950

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

955f950

responsibility to make sure "overburn" condition is not

955f950

raised. As of version 5.2 growisofs performs the necessary checks

955f950

for you and refuses to start recording if "overburn"

955f950

condition appears to be unavoidable. This behaviour can be overridden

955f950

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

955f950


If you're satisfied with growisofs, then you

955f950

should just proceed to the next chapter

955f950

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

955f950

you haven't stopped reading beyond this line,

955f950

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

955f950

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

955f950

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

955f950

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

955f950

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

955f950

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

955f950

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

955f950

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

955f950

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

955f950

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

955f950

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

955f950

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

955f950

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

955f950

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

955f950

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

955f950

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

955f950

your original Linux source code ditribution.-->

955f950

Linux 2.6 DVD+RW kernel support is planned in

955f950

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

955f950

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

955f950

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

955f950

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

955f950

Philips DVDRW416K or BenQ DW400A do not actually implement

955f950

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

955f950

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

955f950

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

955f950

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

955f950

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

955f950

software in opposite to Mt.Rainier firmware).

955f950

Even though kernel now

955f950

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

955f950

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

955f950

tempting it might appear.

955f950

As you might know DVD+RW media can sustain only

955f950

around 1000 overwrites. The thing about fully fledged file systems

955f950

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

955f950

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

955f950

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

955f950

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

955f950

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

955f950

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

955f950

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

955f950

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

955f950

year [

955f950

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

955f950

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

955f950

[in firmware, a.k.a.

955f950

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

955f950

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

955f950

file system driver should definitely refrain from modifying the

955f950

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

955f950

last mount. Given the development status of

955f950

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

955f950

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

955f950

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

955f950

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

955f950

UDF write support is unfortunately disabled and you might have to

955f950

reconfigure the kernel and rebuild modules. Alternatively [my preferred

955f950

option actually] fetch the code at

955f950

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

955f950

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

955f950

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

955f950

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

955f950

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

955f950

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

955f950

by UDF maintainer, Ben Fennema.

955f950


Performance optimization. This paragraph

955f950

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

955f950

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

955f950

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

955f950

so, as common block device layer completely reorganizes the

955f950

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

955f950

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

955f950

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

955f950

through block buffer cache. To minimize the pressure and improve

955f950

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

955f950

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

955f950

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

955f950

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

955f950

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

955f950

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

955f950

out, consider

955f950

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

955f950

"hacklet"...

955f950

Compatibility: caveat lector

955f950

This paragraph discusses "DVD-ROM

955f950

compatibility," or playability of already recorded media in legacy

955f950

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

955f950

start or fulfill recording because of poor media support by burner

955f950

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

955f950

supported media and/or to the

955f950

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

955f950

experience.

955f950

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

955f950

calibrate their mechanics every time the media is loaded by sliding

955f950

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

955f950

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

955f950

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

e8532ab

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

955f950

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

955f950

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

e8532ab

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

955f950

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

955f950

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

955f950

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

e8532ab

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

e8532ab

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

e8532ab

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

e8532ab

to

955f950

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

955f950

COLOR="red">N</FONT>

955f950

which relocates the lead-out next to outermost

955f950

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

955f950

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

955f950

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

955f950

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

955f950

lead-out.-->

955f950

e8532ab

Then non-finalized DVD+R and Sequential

e8532ab

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

e8532ab

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

e8532ab

remaining space for immediate compatibility, just fill the media

e8532ab

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

e8532ab

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

e8532ab

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

e8532ab

the real lead-out directly after the first session.

955f950

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

955f950

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

955f950

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

955f950

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

955f950

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

955f950

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

955f950

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

e8532ab

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

955f950

</FONT>

955f950

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

955f950

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

955f950

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

955f950

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

955f950

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

955f950

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

955f950

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

955f950

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

955f950

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

955f950

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

955f950

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

955f950

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

955f950

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

955f950

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

955f950

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

955f950

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

955f950

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

955f950

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

955f950

Then we have logical format compatibility

955f950

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

955f950

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

955f950

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

955f950

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

955f950

format specifications don't explicitly say that unrecognized format

955f950

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

e8532ab

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

e8532ab

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

e8532ab

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

e8532ab

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

e8532ab

apparently by "traditional" DVD+RW vendors and not

e8532ab

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

e8532ab

secret vendor-specific command

955f950

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

955f950

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

955f950

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

955f950

COLOR="red">N</FONT>

955f950

Once again. Not all vendors support this and you

955f950

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

955f950

It's naturally not possible to manipulate the

955f950

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

955f950

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

955f950

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

955f950

going to be branded by programming the drive in advance:

955f950

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

955f950

COLOR="red">N</FONT>

955f950

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

955f950

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

955f950

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

955f950

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

955f950

Bitsettings" article at dvdplusrw.org.

955f950

There [potentially] are other logical

955f950

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

955f950

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

955f950

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

955f950

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

955f950

Recognition of other incompatibilities would require cooperation from

e8532ab

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

e8532ab

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

e8532ab

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

955f950

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

955f950

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

e8532ab

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

e8532ab

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

e8532ab

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

955f950

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

955f950

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

955f950

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

955f950

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

955f950

development initiative.</FONT>

955f950

Finally there is a physical incompatibility issue.

955f950

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

955f950

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

955f950

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

e8532ab

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

e8532ab

distinguish physical from logical format incompatibility, which I find

e8532ab

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

955f950

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

955f950

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

e8532ab

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

e8532ab

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

e8532ab

that if player makes assumptions about linear pit density based on

955f950

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

955f950

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

955f950

player...

955f950

Technical Ramblings

955f950

ALIGN="RIGHT">

955f950

e8532ab

As for multisession ISO9660 [DVD]

e8532ab

recordings! Unfortunately, Linux ISOFS implementation had certain

955f950

deficiency which limits interoperability of such recordings. In order

955f950

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

955f950

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

955f950

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

955f950

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

955f950

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

955f950

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

955f950

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

955f950

collects all the directories in the beginning of any particular session

955f950

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

955f950

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

955f950

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

955f950

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

955f950

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

955f950

particular not in further sessions. Having noted that directory entries

955f950

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

955f950

it's perfectly possible to

e8532ab

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

e8532ab

maximum interoperability, you should not let any session

955f950

start past 4GB minus space required for directory

955f950

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

955f950

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

955f950

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

955f950

pretty much arbitrary chosen large value, large for directory catalogs

955f950

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

e8532ab

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

955f950

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

955f950

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

955f950

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

955f950

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

e8532ab

broader compatibility of final DVD recordings. This check is not

e8532ab

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

e8532ab

such user community would run something elder than 2.6.9 is considered

e8532ab

diminishingly low.

955f950

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

955f950

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

955f950

file in a file system</FONT>

955f950

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

955f950

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

955f950

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

955f950

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

955f950

kernel developers only;-)</FONT>

955f950

Why media reload is performed after every

955f950

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

e8532ab

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

955f950

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

e8532ab

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

955f950

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

955f950

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

955f950

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

955f950

unaware of growisofs activities, growisofs bypasses the block

955f950

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

955f950

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

e8532ab

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

e8532ab

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

e8532ab

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

e8532ab

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

e8532ab

access beyond end of device."

955f950

What does [kernel] "DVD+RW support"

955f950

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

955f950

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

955f950

"CLOSE TRACK/SESSION (5Bh)"

955f950

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

955f950

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

955f950

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

955f950

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

955f950

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

955f950

"finalizing" at unlock door.

955f950

Secondly, whenever you employ fully fledged

955f950

file system, I/O requests get inevitably fragmented.

955f950

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

955f950

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

955f950

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

955f950

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

955f950

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

955f950

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

955f950

order to optimize the process certain caching algorithm is implemented

955f950

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

955f950

situations. And so in such unfortunate situations the drive apparently

955f950

stops processing I/O requests returning "COMMAND SEQUENCE ERROR

955f950

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

955f950

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

955f950

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

955f950

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

955f950

flow.

955f950

Unfortunately the above paragraph doesn't

955f950

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

955f950

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

955f950

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

955f950

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

955f950

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

955f950

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

955f950

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

955f950

[but not the same] behaviour under apparently extremely rare

955f950

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

955f950

reportedly disappears with firmware upgrade...

955f950

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

955f950

most vendors, seem to not bother about complying with

955f950

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

955f950

granularity" part in particular. Instead they apparently expect

955f950

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

955f950

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

955f950

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

955f950

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

955f950

it's the reality of marketplace:-(

955f950

This one really beats me. Sometimes the unit

955f950

simply stops writing signaling a vendor specific positioning error,

955f950

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

955f950

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

955f950

requests so that they are not sequential anymore, "FLUSH

955f950

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

955f950

"underrun" condition background formatting kicks off and has

955f950

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

955f950

the unit is supposed to handle temporary data stream outages

955f950

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

955f950

complement growisofs command line with [undocumented]

955f950

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

955f950

This option eliminates request reorders and minimizes possibility for

955f950

"underrun" condition (by releasing the pressure off VM

955f950

subsystem).

955f950

The original idea was to implement DVD+RW support in

955f950

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

955f950

"writeable" flag controlling the ability to issue WRITE

955f950

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

955f950

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

955f950

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

955f950

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

955f950

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

955f950

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

955f950

Unfortunately it was not possible to implement it

955f950

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

955f950

modification was required to sense the media before decision about

955f950

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

955f950

morphing their behaviour after currently mounted media and it's

955f950

essential to identify newly inserted media.

955f950

Special comment about "what a dirty

955f950

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

955f950

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

955f950

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

955f950

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

955f950

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

955f950

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

955f950

unused bits from the "quiet" argument instead of modifying

955f950

all the calls (too boring).

955f950

But even if time-out value passed down to kernel

955f950

(with either CDROM_SEND_PACKET or SG_IO ioctl) is taken into

955f950

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

955f950

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

955f950

CDROM_SEND_PACKET, but following the common sense most programmers

955f950

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

955f950

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

955f950

in turn is

955f950

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

955f950

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

955f950

treats these values as "jiffies," which is a

955f950

platform-dependent value representing time elapsed between timer

955f950

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

955f950

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

955f950

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

955f950

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

955f950

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

955f950

nor scale timeouts

955f950

accordingly in respect to the legacy value of 10ms.

955f950

There is another kernel "deficiency" I ran

955f950

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

955f950

The drive provides background formatting progress status, but

955f950

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

955f950

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

955f950

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

955f950

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

955f950

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

955f950

As you might have noticed the time-out value for

955f950

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

955f950

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

955f950

when reformatting used media. Formatting of the blank

955f950

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

955f950

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

955f950

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

955f950

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

955f950

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

955f950

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

955f950

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

955f950

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

955f950

manufacturing and want formatted capacity to reflect data set size.

955f950

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

955f950

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

955f950

"finalize" the media.

955f950

-->

955f950

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

955f950

Acard SCSI to

955f950

IDE bridges.

955f950

What does

955f950

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

955f950

stand for? Originally this paragraph started as following:

955f950

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

955f950

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

955f950

information modulated into it. This makes it possible to resume

955f950

interrupted [or deliberately suspended] burning process with accuracy

955f950

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

955f950

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

955f950

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

955f950

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

955f950

Now given that both provided and tolerated inaccuracies are

955f950

proportional to respectively writing and reading velocities there

955f950

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

955f950

buffer underrun will be universally playable.

955f950

Well, it turned out that I was wrong about one

955f950

thing.

955f950

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

955f950

groove also provides for adequately accurate recovery from

955f950

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

955f950

but accurate enough for splices to be playable in virtually any

e8532ab

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

e8532ab

specificaton apparently insists that you choose between

955f950

buffer underrun protection and

955f950

full DVD-ROM/-Video compatibility.

955f950

e8532ab

The specification asserts that the latter is

e8532ab

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

e8532ab

was maintained uninterrupted throughout whole recording. Once again.

e8532ab

Even though most vendors implement lossless linking in DAO

e8532ab

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

e8532ab

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

e8532ab

problem is that "offended" sectors are denoted with certain

e8532ab

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

e8532ab

are supposed to be "corrected away" by ECC

e8532ab

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

e8532ab

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

e8532ab

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

e8532ab

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

e8532ab

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

e8532ab

[unconditional] buffer underrun protection.

955f950

As already mentioned, DVD+ groove has

955f950

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

955f950

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

955f950

arbitrary order, even to virgin surface and practically instantly

955f950

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

955f950

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

955f950

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

955f950

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

955f950

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

955f950

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

955f950

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

955f950

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

955f950

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

955f950

suspended at any time without any side effects. Consider following

955f950

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

955f950

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

955f950

retrieve previously recorded data. This would naturally require

955f950

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

955f950

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

955f950

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

955f950

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

955f950

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

955f950

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

955f950

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

955f950

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

955f950

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

955f950

is instant regardless media state.

955f950

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

955f950

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

955f950

themselves. Apparently a couple of "guiding" words are

955f950

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

955f950

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

e8532ab

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

e8532ab

recordings are children's game...

955f950

Sometimes DVD+RW/+R recording strategy is referred

955f950

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

955f950

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

955f950

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

955f950

packets/extents are still denoted with certain linking information

955f950

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

955f950

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

955f950

Data Zone, does not contain any linking information and is

955f950

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

955f950

mode (or DVD-ROM for that matter).

955f950

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

955f950

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

955f950

it quite resistant to dust, scratches, etc.

955f950

e8532ab

Now we can also discuss differences between

e8532ab

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

e8532ab

arbitrary layer break positioning yet maintaining contiguous logical

e8532ab

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

e8532ab

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

e8532ab

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

e8532ab

other hand implies unconditionally disjoint logical block addressing

e8532ab

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

e8532ab

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

e8532ab

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

e8532ab

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

e8532ab

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

e8532ab

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

e8532ab

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

e8532ab

Unlike DVD+plus that is.

e8532ab

955f950

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

955f950

<FONT SIZE="-1">According to

e8532ab

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

e8532ab

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

e8532ab

buffer under-run occurs, the logical unit shall stop

e8532ab

writing immediately and the logical unit shall start

e8532ab

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

e8532ab

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

e8532ab

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

e8532ab

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

e8532ab

implementation being discussed here.</FONT>

955f950

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

955f950

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

955f950

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

955f950

playability.</FONT>

955f950

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

955f950

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

955f950

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

955f950

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

955f950

back.</FONT>

955f950

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

955f950

</BODY>

955f950

</HTML>

rpms / dvd+rw-tools

Source Code

Blame index.html

Blu-ray Disc/

by <appro@fy.chalmers.se>,

Foreword

Tutorial

Compatibility: caveat lector

Technical Ramblings