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

rpms / dvd+rw-tools

Blame SOURCES/index.html

Blob History Raw

<HTML>

6b477d

<HEAD>

6b477d

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

6b477d

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

6b477d

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

6b477d

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

6b477d

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

6b477d

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

6b477d

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

6b477d

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

6b477d

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

6b477d

			       multisession, growisofs">

6b477d

				  user-land utilities and optional Linux

6b477d

				  kernel patch">

6b477d

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

6b477d

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

6b477d

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

6b477d

</HEAD>

6b477d

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

6b477d

Blu-ray Disc/

6b477d

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

6b477d

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

6b477d

by <appro@fy.chalmers.se>,

6b477d

September 2006

6b477d

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

6b477d

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

6b477d

Q.	What is this page (not) about?

6b477d

A.<SUP> </SUP>

6b477d

	Maybe to your disappointment it is not about

6b477d

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

6b477d

	computer storage applications of Blu-ray Disc and

6b477d

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

6b477d

	exchange... The downloadable files are an optional

6b477d

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

6b477d

	couple of user-land utilities dubbed as <NOBR>

6b477d

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

6b477d

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

6b477d

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

6b477d

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

6b477d

	is "molded" in an ordinary data file system and

6b477d

	therefore no explicit support by the burning program is

6b477d

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

6b477d

	content preparation which is beyond the scope of this

6b477d

	page.</FONT>

6b477d

Q.	Kernel patch? This sounds too complicated

6b477d

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

6b477d

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

6b477d

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

6b477d

	without explicit kernel support. So if they

6b477d

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

6b477d

	patching the kernel is by all means optional. As

6b477d

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

6b477d

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

6b477d

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

6b477d

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

6b477d

	7.3 Release Notes say). On additional note Linux kernel

6b477d

	version 2.6>=10 is equipped with

6b477d

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

6b477d

	writing driver which supports even DVD rewritable media,

6b477d

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

6b477d

Q.	What is the kernel patch good for then?

6b477d

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

6b477d

	write access media and therefore is suitable for housing of an

6b477d

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

6b477d

	and this alone, qualifies DVD+RW support for kernel

6b477d

	implementation. However, I have to recommend to

6b477d

	deploy it with caution, see tutorial

6b477d

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

6b477d

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

6b477d

	moment of this writing apparenly only 2nd generation

6b477d

	Ricoh-based units (see

6b477d

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

6b477d

	generation listings) equipped with later firmware can sustain

6b477d

	I/O fragmentation (see Technical Ramblings below for further

6b477d

	details) and perform reliably.

6b477d

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

6b477d

A.	As implied/already mentioned - to master the

6b477d

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

6b477d

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

6b477d

	tutorial below, but figured that couple of words about the

6b477d

	[original] design ideas behind growisofs, the principal

6b477d

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

6b477d

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

6b477d

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

6b477d

	likely want to access the data on an arbitrary computer.

6b477d

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

6b477d

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

6b477d

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

6b477d

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

6b477d

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

6b477d

	Well, yes, unless you employ growisofs! Growisofs

6b477d

	provides the way to both lay down and grow an ISO9660

6b477d

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

6b477d

	image to) all supported optical media.

6b477d

Q.	But if they support  both + and - recording

6b477d

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

6b477d

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

6b477d

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

6b477d

	vast majority of DVD burners that are being introduced to the

6b477d

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

6b477d

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

6b477d

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

6b477d

	"seamless" multisessioning, not as reference to some

6b477d

	particular format:-)

6b477d

Q.	Do I still need

6b477d

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

6b477d

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

6b477d

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

6b477d

	actual ISO9660 file system layout. Secondly, the DVD burners

6b477d

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

6b477d

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

6b477d

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

6b477d

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

6b477d

	dvd+rw-tools with it/them?

6b477d

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

6b477d

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

6b477d

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

6b477d

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

6b477d

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

6b477d

	dvd+rw-tools provide experimental support even for

6b477d

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

6b477d

	dedicated page for further details.

6b477d

-->

6b477d

Q.	Does it work with my recorder unit?

6b477d

A.	If your unit is

6b477d

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

6b477d

	then the answer is "most likely it

6b477d

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

6b477d

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

6b477d

	unconditionally "most likely."

6b477d

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

6b477d

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

6b477d

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

6b477d

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

6b477d

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

6b477d

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

6b477d

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

6b477d

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

6b477d

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

6b477d

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

6b477d

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

6b477d

	the least all-mighty

6b477d

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

6b477d

Q.	Is there a GUI front-end available for

6b477d

	dvd+rw-tools?

6b477d

A.	K3b, version 0.10

6b477d

	and later, and

6b477d

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

6b477d

	version 0.5.1 and later, are both hiding growisofs behind their

6b477d

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

6b477d

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

6b477d

	effort and GUI users should turn elsewhere for end-user

6b477d

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

6b477d

	GUI frontends...

6b477d

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

6b477d

A.	Version 5.4 adds support for

6b477d

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

6b477d

	Version 5.6 adds support for Solaris 2.x

6b477d

	SIZE=-1>[commercial licensing

6b477d

	terms for distribution on Solaris are to be settled with

6b477d

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

6b477d

	Version 5.8 features

6b477d

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

6b477d

	port contributed by Matthew Dillon, FreeBSD Development Team

6b477d

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

6b477d

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

6b477d

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

6b477d

	5.19, Win32 one - in 6.0,

6b477d

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

6b477d

¡

6b477d

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

6b477d

	separately available [and unless stated otherwise], do use

6b477d

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

6b477d

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

6b477d

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

6b477d

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

6b477d

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

6b477d

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

6b477d

	you might have to mount

6b477d

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

6b477d

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

6b477d

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

6b477d

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

6b477d

	undergone HP quality assurance testing

6b477d

	and is delivered on HP

6b477d

	software depot.</FONT>

6b477d

Foreword

6b477d

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

6b477d

turn to <

6b477d

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

6b477d

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

6b477d

to be subscribed to post

6b477d

a problem report. List archives can be found at both

6b477d

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

6b477d

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

6b477d

When submitting report, provide versioning information, exact

6b477d

command line, exact output generated by the program and

6b477d

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

6b477d

resulting recording. Do check couple of last

6b477d

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

6b477d

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

6b477d

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

6b477d

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

6b477d

attentively...

6b477d

Special thanks for hardware donations [in

6b477d

chronological order]:

6b477d

ALT="Inserve Technology" BORDER=0>

6b477d

ALT="HP" BORDER=0>

6b477d

ALT="LinuxFund" BORDER=0>

6b477d

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

6b477d

Tutorial

6b477d


If your burner unit is managed by some

6b477d

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

6b477d

automounting/autoplaying facility, such as autofs, supermount,

6b477d

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

6b477d

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

6b477d

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

6b477d

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

6b477d

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

6b477d

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

6b477d

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

6b477d

recordings.

6b477d

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

6b477d

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

6b477d

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

6b477d

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

6b477d

under their control.</FONT>

6b477d


Remember to consult

6b477d

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

6b477d

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

6b477d

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

6b477d

enough to bring it up already here:-)

6b477d


If you have an IDE unit and run 2.4.x

6b477d

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

6b477d

emulation layer by either:

6b477d

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

6b477d

argument to kernel;

6b477d

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

6b477d

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

6b477d

pre-install sg modprobe ide-scsi

6b477d

pre-install sr_mod modprobe ide-scsi

6b477d

pre-install ide-scsi modprobe ide-cd

6b477d

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

6b477d

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

6b477d

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

6b477d

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

6b477d

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

6b477d

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

6b477d

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

6b477d

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

6b477d

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

6b477d

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

6b477d

some IDE chipsets...</FONT>

6b477d


If you have an external unit, just get

6b477d

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

6b477d

whatsoever with USB or

6b477d

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

6b477d

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

6b477d

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

6b477d

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

6b477d

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

6b477d

connected drives were reported to be working fine since eternity.

6b477d

Firewire connected drives in turn were reported to fail miserably under

6b477d

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

6b477d

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

6b477d

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

6b477d

work with this and later kernels.

6b477d


If you're running 2.4.19 or .20, consider

6b477d

applying this drivers/scsi/sg.c patch.

6b477d

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

6b477d

"do" for the following reasons:

6b477d

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

6b477d

interface), cdrecord [potentially] is;

6b477d

I however haven't actually experienced the problem with cdrecord

6b477d

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

6b477d

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

6b477d

failed miserably on me;

6b477d

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

6b477d

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

6b477d

where "generic" SCSI interface can be bypassed by issuing

6b477d

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

6b477d

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

6b477d

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

6b477d

patches #1 and

6b477d

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

6b477d

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

6b477d

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

6b477d

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

6b477d

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

6b477d

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

6b477d

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

6b477d

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

6b477d

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

6b477d

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

6b477d

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

6b477d

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

6b477d

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

6b477d

"supported" recommendation is to just stay away from this

6b477d

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

6b477d

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

6b477d

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

6b477d

utility works only with limited number of units, installation procedure

6b477d

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

6b477d

this security sensitive choice to the end-user.

6b477d


Download, unpack and compile the

6b477d

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

6b477d

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

6b477d

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

6b477d

source code files found in the download catalog

6b477d

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

6b477d

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

6b477d

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

6b477d

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

6b477d

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

6b477d

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

6b477d

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

6b477d

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

6b477d

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

6b477d

CDROM_SEND_PACKET ioctl deployed by dvd+rw-tools.

6b477d


As new media products and brands are being

6b477d

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

6b477d

periodically check for firmware updates. For elder units

6b477d

firmware update might even be an absolute requirement for using

6b477d

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

6b477d

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

6b477d

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

6b477d

files in

6b477d

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

6b477d

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

6b477d


Formatting the BD and DVD+RW media.

6b477d

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

6b477d

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

6b477d

formatted. As of version 5.10 growisofs detects blanks and applies

6b477d

initial formatting procedure automatically. Otherwise same effect can

6b477d

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

6b477d

argument to dvd+rw-format. Well,

6b477d

in BD case it does offer more flexibility than

6b477d

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

6b477d

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

6b477d

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

6b477d

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

6b477d

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

6b477d

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

6b477d

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

6b477d

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

6b477d

so is one of BD.

6b477d

It was observed that excessive reformats can render

6b477d

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

6b477d

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

6b477d

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

6b477d

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

6b477d

Note that re-formatting procedure does not

6b477d

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

6b477d

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

6b477d

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

6b477d

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

6b477d

re-formatting is required.

6b477d

DVD+R media does not require any formatting

6b477d

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

6b477d

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

6b477d

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

6b477d


Burning with

6b477d

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

6b477d

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

6b477d

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

6b477d

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

6b477d

consult mkisofs manual page and

6b477d

accompanying reference documentation (including multisession related

6b477d

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

6b477d

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

6b477d

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

6b477d

are:

6b477d

you may not use -o option;

6b477d

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

6b477d

for you;

6b477d

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

6b477d

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

6b477d

Otherwise everything that applies to

6b477d

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

6b477d

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

6b477d

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

6b477d

them, e.g.:

6b477d

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

6b477d

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

6b477d

Oh! Do make sure you have at least mkisofs

6b477d

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

6b477d

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

6b477d

other words consider deploying growisofs for incremental

6b477d

multisession backups, then you shall find

6b477d

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

6b477d

mkisofs <FONT COLOR="red">2

6b477d

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

6b477d

The idea and implementation by

6b477d

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

6b477d

"graft" recording sessions as separate directories. Each

6b477d

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

6b477d

references to previously backed up ones, which facilitates

6b477d

comparison between increments as well as fine-graded restore.

6b477d

Number of users asked about opposite to

6b477d

multisessioning: multivolume support. Being essentially a recording

6b477d

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

6b477d

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

6b477d

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

6b477d

shunt. But back to

6b477d

growisofs...

6b477d

In addition to intuitive -Z interpretation,

6b477d

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

6b477d

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

6b477d

"magic" command is:

6b477d

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

6b477d

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

6b477d

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

6b477d

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

6b477d

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

6b477d

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

6b477d

arbitrary program, you can use:

6b477d

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

6b477d

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

6b477d

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

6b477d

option<TT>:-)</TT>

6b477d

Apparently media needs to be manually reloaded [ejected and pushed

6b477d

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

6b477d

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

6b477d

--->

6b477d

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

6b477d

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

6b477d

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

6b477d

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

6b477d

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

6b477d

capable to access data added at different occasions.

6b477d

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

6b477d

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

6b477d

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

6b477d

work it around by reloading corresponding driver, most likely

6b477d

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

6b477d

Linux kernel 2.6<

6b477d

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

6b477d

users might experience

6b477d

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

6b477d

mounting multisession media with last session starting beyond

6b477d

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

6b477d

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

6b477d

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

6b477d

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

6b477d

mkisofs from cdrtools-2.0

6b477d

or later or apply this patch.

6b477d

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

6b477d

Dual Layer recordings, growisofs applies yet another limitation,

6b477d

purely artificial. Taking into consideration Double Layer media prices

6b477d

growisofs is programmed to refuse to perform unappendable

6b477d

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

6b477d

to use single layer media instead.

6b477d

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

6b477d

discussed on the -RW companion page. Once

6b477d

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

6b477d

recordings come out unappendable and can not be grown.

6b477d

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

6b477d

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

6b477d

translated to "real" GB, single layer

6b477d

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

6b477d

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

6b477d

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

6b477d

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

6b477d

responsibility to make sure "overburn" condition is not

6b477d

raised. As of version 5.2 growisofs performs the necessary checks

6b477d

for you and refuses to start recording if "overburn"

6b477d

condition appears to be unavoidable. This behaviour can be overridden

6b477d

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

6b477d


If you're satisfied with growisofs, then you

6b477d

should just proceed to the next chapter

6b477d

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

6b477d

you haven't stopped reading beyond this line,

6b477d

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

6b477d

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

6b477d

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

6b477d

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

6b477d

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

6b477d

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

6b477d

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

6b477d

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

6b477d

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

6b477d

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

6b477d

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

6b477d

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

6b477d

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

6b477d

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

6b477d

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

6b477d

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

6b477d

your original Linux source code ditribution.-->

6b477d

Linux 2.6 DVD+RW kernel support is planned in

6b477d

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

6b477d

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

6b477d

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

6b477d

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

6b477d

Philips DVDRW416K or BenQ DW400A do not actually implement

6b477d

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

6b477d

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

6b477d

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

6b477d

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

6b477d

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

6b477d

software in opposite to Mt.Rainier firmware).

6b477d

Even though kernel now

6b477d

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

6b477d

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

6b477d

tempting it might appear.

6b477d

As you might know DVD+RW media can sustain only

6b477d

around 1000 overwrites. The thing about fully fledged file systems

6b477d

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

6b477d

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

6b477d

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

6b477d

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

6b477d

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

6b477d

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

6b477d

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

6b477d

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

6b477d

year [

6b477d

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

6b477d

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

6b477d

[in firmware, a.k.a.

6b477d

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

6b477d

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

6b477d

file system driver should definitely refrain from modifying the

6b477d

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

6b477d

last mount. Given the development status of

6b477d

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

6b477d

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

6b477d

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

6b477d

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

6b477d

UDF write support is unfortunately disabled and you might have to

6b477d

reconfigure the kernel and rebuild modules. Alternatively [my preferred

6b477d

option actually] fetch the code at

6b477d

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

6b477d

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

6b477d

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

6b477d

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

6b477d

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

6b477d

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

6b477d

by UDF maintainer, Ben Fennema.

6b477d


Performance optimization. This paragraph

6b477d

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

6b477d

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

6b477d

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

6b477d

so, as common block device layer completely reorganizes the

6b477d

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

6b477d

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

6b477d

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

6b477d

through block buffer cache. To minimize the pressure and improve

6b477d

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

6b477d

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

6b477d

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

6b477d

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

6b477d

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

6b477d

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

6b477d

out, consider

6b477d

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

6b477d

"hacklet"...

6b477d

Compatibility: caveat lector

6b477d

This paragraph discusses "DVD-ROM

6b477d

compatibility," or playability of already recorded media in legacy

6b477d

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

6b477d

start or fulfill recording because of poor media support by burner

6b477d

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

6b477d

supported media and/or to the

6b477d

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

6b477d

experience.

6b477d

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

6b477d

calibrate their mechanics every time the media is loaded by sliding

6b477d

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

6b477d

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

6b477d

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

6b477d

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

6b477d

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

6b477d

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

6b477d

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

6b477d

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

6b477d

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

6b477d

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

6b477d

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

6b477d

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

6b477d

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

6b477d

to

6b477d

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

6b477d

COLOR="red">N</FONT>

6b477d

which relocates the lead-out next to outermost

6b477d

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

6b477d

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

6b477d

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

6b477d

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

6b477d

lead-out.-->

6b477d

Then non-finalized DVD+R and Sequential

6b477d

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

6b477d

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

6b477d

remaining space for immediate compatibility, just fill the media

6b477d

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

6b477d

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

6b477d

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

6b477d

the real lead-out directly after the first session.

6b477d

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

6b477d

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

6b477d

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

6b477d

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

6b477d

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

6b477d

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

6b477d

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

6b477d

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

6b477d

</FONT>

6b477d

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

6b477d

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

6b477d

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

6b477d

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

6b477d

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

6b477d

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

6b477d

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

6b477d

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

6b477d

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

6b477d

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

6b477d

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

6b477d

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

6b477d

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

6b477d

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

6b477d

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

6b477d

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

6b477d

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

6b477d

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

6b477d

Then we have logical format compatibility

6b477d

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

6b477d

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

6b477d

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

6b477d

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

6b477d

format specifications don't explicitly say that unrecognized format

6b477d

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

6b477d

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

6b477d

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

6b477d

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

6b477d

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

6b477d

apparently by "traditional" DVD+RW vendors and not

6b477d

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

6b477d

secret vendor-specific command

6b477d

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

6b477d

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

6b477d

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

6b477d

COLOR="red">N</FONT>

6b477d

Once again. Not all vendors support this and you

6b477d

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

6b477d

It's naturally not possible to manipulate the

6b477d

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

6b477d

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

6b477d

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

6b477d

going to be branded by programming the drive in advance:

6b477d

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

6b477d

COLOR="red">N</FONT>

6b477d

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

6b477d

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

6b477d

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

6b477d

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

6b477d

Bitsettings" article at dvdplusrw.org.

6b477d

There [potentially] are other logical

6b477d

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

6b477d

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

6b477d

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

6b477d

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

6b477d

Recognition of other incompatibilities would require cooperation from

6b477d

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

6b477d

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

6b477d

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

6b477d

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

6b477d

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

6b477d

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

6b477d

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

6b477d

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

6b477d

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

6b477d

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

6b477d

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

6b477d

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

6b477d

development initiative.</FONT>

6b477d

Finally there is a physical incompatibility issue.

6b477d

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

6b477d

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

6b477d

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

6b477d

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

6b477d

distinguish physical from logical format incompatibility, which I find

6b477d

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

6b477d

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

6b477d

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

6b477d

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

6b477d

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

6b477d

that if player makes assumptions about linear pit density based on

6b477d

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

6b477d

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

6b477d

player...

6b477d

Technical Ramblings

6b477d

ALIGN="RIGHT">

6b477d

As for multisession ISO9660 [DVD]

6b477d

recordings! Unfortunately, Linux ISOFS implementation had certain

6b477d

deficiency which limits interoperability of such recordings. In order

6b477d

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

6b477d

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

6b477d

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

6b477d

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

6b477d

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

6b477d

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

6b477d

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

6b477d

collects all the directories in the beginning of any particular session

6b477d

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

6b477d

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

6b477d

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

6b477d

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

6b477d

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

6b477d

particular not in further sessions. Having noted that directory entries

6b477d

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

6b477d

it's perfectly possible to

6b477d

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

6b477d

maximum interoperability, you should not let any session

6b477d

start past 4GB minus space required for directory

6b477d

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

6b477d

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

6b477d

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

6b477d

pretty much arbitrary chosen large value, large for directory catalogs

6b477d

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

6b477d

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

6b477d

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

6b477d

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

6b477d

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

6b477d

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

6b477d

broader compatibility of final DVD recordings. This check is not

6b477d

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

6b477d

such user community would run something elder than 2.6.9 is considered

6b477d

diminishingly low.

6b477d

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

6b477d

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

6b477d

file in a file system</FONT>

6b477d

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

6b477d

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

6b477d

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

6b477d

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

6b477d

kernel developers only;-)</FONT>

6b477d

Why media reload is performed after every

6b477d

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

6b477d

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

6b477d

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

6b477d

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

6b477d

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

6b477d

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

6b477d

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

6b477d

unaware of growisofs activities, growisofs bypasses the block

6b477d

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

6b477d

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

6b477d

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

6b477d

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

6b477d

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

6b477d

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

6b477d

access beyond end of device."

6b477d

What does [kernel] "DVD+RW support"

6b477d

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

6b477d

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

6b477d

"CLOSE TRACK/SESSION (5Bh)"

6b477d

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

6b477d

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

6b477d

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

6b477d

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

6b477d

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

6b477d

"finalizing" at unlock door.

6b477d

Secondly, whenever you employ fully fledged

6b477d

file system, I/O requests get inevitably fragmented.

6b477d

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

6b477d

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

6b477d

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

6b477d

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

6b477d

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

6b477d

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

6b477d

order to optimize the process certain caching algorithm is implemented

6b477d

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

6b477d

situations. And so in such unfortunate situations the drive apparently

6b477d

stops processing I/O requests returning "COMMAND SEQUENCE ERROR

6b477d

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

6b477d

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

6b477d

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

6b477d

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

6b477d

flow.

6b477d

Unfortunately the above paragraph doesn't

6b477d

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

6b477d

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

6b477d

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

6b477d

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

6b477d

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

6b477d

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

6b477d

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

6b477d

[but not the same] behaviour under apparently extremely rare

6b477d

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

6b477d

reportedly disappears with firmware upgrade...

6b477d

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

6b477d

most vendors, seem to not bother about complying with

6b477d

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

6b477d

granularity" part in particular. Instead they apparently expect

6b477d

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

6b477d

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

6b477d

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

6b477d

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

6b477d

it's the reality of marketplace:-(

6b477d

This one really beats me. Sometimes the unit

6b477d

simply stops writing signaling a vendor specific positioning error,

6b477d

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

6b477d

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

6b477d

requests so that they are not sequential anymore, "FLUSH

6b477d

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

6b477d

"underrun" condition background formatting kicks off and has

6b477d

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

6b477d

the unit is supposed to handle temporary data stream outages

6b477d

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

6b477d

complement growisofs command line with [undocumented]

6b477d

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

6b477d

This option eliminates request reorders and minimizes possibility for

6b477d

"underrun" condition (by releasing the pressure off VM

6b477d

subsystem).

6b477d

The original idea was to implement DVD+RW support in

6b477d

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

6b477d

"writeable" flag controlling the ability to issue WRITE

6b477d

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

6b477d

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

6b477d

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

6b477d

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

6b477d

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

6b477d

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

6b477d

Unfortunately it was not possible to implement it

6b477d

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

6b477d

modification was required to sense the media before decision about

6b477d

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

6b477d

morphing their behaviour after currently mounted media and it's

6b477d

essential to identify newly inserted media.

6b477d

Special comment about "what a dirty

6b477d

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

6b477d

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

6b477d

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

6b477d

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

6b477d

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

6b477d

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

6b477d

unused bits from the "quiet" argument instead of modifying

6b477d

all the calls (too boring).

6b477d

But even if time-out value passed down to kernel

6b477d

(with either CDROM_SEND_PACKET or SG_IO ioctl) is taken into

6b477d

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

6b477d

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

6b477d

CDROM_SEND_PACKET, but following the common sense most programmers

6b477d

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

6b477d

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

6b477d

in turn is

6b477d

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

6b477d

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

6b477d

treats these values as "jiffies," which is a

6b477d

platform-dependent value representing time elapsed between timer

6b477d

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

6b477d

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

6b477d

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

6b477d

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

6b477d

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

6b477d

nor scale timeouts

6b477d

accordingly in respect to the legacy value of 10ms.

6b477d

There is another kernel "deficiency" I ran

6b477d

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

6b477d

The drive provides background formatting progress status, but

6b477d

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

6b477d

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

6b477d

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

6b477d

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

6b477d

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

6b477d

As you might have noticed the time-out value for

6b477d

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

6b477d

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

6b477d

when reformatting used media. Formatting of the blank

6b477d

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

6b477d

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

6b477d

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

6b477d

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

6b477d

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

6b477d

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

6b477d

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

6b477d

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

6b477d

manufacturing and want formatted capacity to reflect data set size.

6b477d

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

6b477d

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

6b477d

"finalize" the media.

6b477d

-->

6b477d

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

6b477d

Acard SCSI to

6b477d

IDE bridges.

6b477d

What does

6b477d

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

6b477d

stand for? Originally this paragraph started as following:

6b477d

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

6b477d

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

6b477d

information modulated into it. This makes it possible to resume

6b477d

interrupted [or deliberately suspended] burning process with accuracy

6b477d

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

6b477d

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

6b477d

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

6b477d

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

6b477d

Now given that both provided and tolerated inaccuracies are

6b477d

proportional to respectively writing and reading velocities there

6b477d

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

6b477d

buffer underrun will be universally playable.

6b477d

Well, it turned out that I was wrong about one

6b477d

thing.

6b477d

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

6b477d

groove also provides for adequately accurate recovery from

6b477d

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

6b477d

but accurate enough for splices to be playable in virtually any

6b477d

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

6b477d

specificaton apparently insists that you choose between

6b477d

buffer underrun protection and

6b477d

full DVD-ROM/-Video compatibility.

6b477d

The specification asserts that the latter is

6b477d

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

6b477d

was maintained uninterrupted throughout whole recording. Once again.

6b477d

Even though most vendors implement lossless linking in DAO

6b477d

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

6b477d

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

6b477d

problem is that "offended" sectors are denoted with certain

6b477d

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

6b477d

are supposed to be "corrected away" by ECC

6b477d

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

6b477d

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

6b477d

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

6b477d

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

6b477d

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

6b477d

[unconditional] buffer underrun protection.

6b477d

As already mentioned, DVD+ groove has

6b477d

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

6b477d

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

6b477d

arbitrary order, even to virgin surface and practically instantly

6b477d

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

6b477d

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

6b477d

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

6b477d

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

6b477d

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

6b477d

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

6b477d

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

6b477d

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

6b477d

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

6b477d

suspended at any time without any side effects. Consider following

6b477d

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

6b477d

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

6b477d

retrieve previously recorded data. This would naturally require

6b477d

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

6b477d

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

6b477d

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

6b477d

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

6b477d

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

6b477d

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

6b477d

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

6b477d

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

6b477d

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

6b477d

is instant regardless media state.

6b477d

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

6b477d

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

6b477d

themselves. Apparently a couple of "guiding" words are

6b477d

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

6b477d

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

6b477d

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

6b477d

recordings are children's game...

6b477d

Sometimes DVD+RW/+R recording strategy is referred

6b477d

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

6b477d

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

6b477d

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

6b477d

packets/extents are still denoted with certain linking information

6b477d

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

6b477d

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

6b477d

Data Zone, does not contain any linking information and is

6b477d

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

6b477d

mode (or DVD-ROM for that matter).

6b477d

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

6b477d

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

6b477d

it quite resistant to dust, scratches, etc.

6b477d

Now we can also discuss differences between

6b477d

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

6b477d

arbitrary layer break positioning yet maintaining contiguous logical

6b477d

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

6b477d

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

6b477d

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

6b477d

other hand implies unconditionally disjoint logical block addressing

6b477d

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

6b477d

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

6b477d

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

6b477d

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

6b477d

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

6b477d

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

6b477d

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

6b477d

Unlike DVD+plus that is.

6b477d

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

6b477d

<FONT SIZE="-1">According to

6b477d

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

6b477d

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

6b477d

buffer under-run occurs, the logical unit shall stop

6b477d

writing immediately and the logical unit shall start

6b477d

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

6b477d

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

6b477d

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

6b477d

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

6b477d

implementation being discussed here.</FONT>

6b477d

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

6b477d

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

6b477d

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

6b477d

playability.</FONT>

6b477d

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

6b477d

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

6b477d

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

6b477d

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

6b477d

back.</FONT>

6b477d

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

6b477d

</BODY>

6b477d

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