<HTML>
<HEAD>
<BASE HREF="http://fy.chalmers.se/~appro/linux/DVD+RW/">
<TITLE>DVD+RW/+R for Linux</TITLE>
<META NAME="keywords" CONTENT="dvd, rewritable, dvd+rw, dvd+r, dvdplusrw, linux">
<META NAME="description" CONTENT="DVD+RW/+R support for Linux: user-land
utilities and optional kernel patch">
<META HTTP-EQUIV="Content-Type" CONTENT="text/html; charset=iso-8859-1">
<LINK REL="icon" HREF="dvdplusrw.ico" TYPE="image/x-icon">
<LINK REL="shortcut icon" HREF="dvdplusrw.ico" TYPE="image/x-icon">
</HEAD>
<BODY BGCOLOR="#C0C0C0" TEXT="#000000"
LINK="#0000D0" VLINK="#502090" ALINK="#FF0000">
<P><HR>
<H1 ALIGN="CENTER"><A HREF="http://www.dvdplusrw.org/">DVD+RW</A>/<A
HREF="#growisofs">+R</A> for Linux</H1>
<H5 ALIGN="CENTER">by <<A
HREF="mailto:appro@fy.chalmers.se">appro@fy.chalmers.se</A>>,
February 2003</H5>
<P><HR>
<P><TABLE CELLPADDING=4>
<TR VALIGN="top" ALIGN="justify">
<TH>Q. <TH ALIGN="left">What is this page (not) about?</TR>
<TR VALIGN="top" ALIGN="justify">
<TD>A. <TD>Maybe to your disappointment it is <B>not</B> about
video<SUP>(*)</SUP>. The scope of this page is primarily
computer storage applications of DVD+RW/+R, things like backup,
archiving, data exchange... The downloadable files are an
<I>optional</I> <A HREF="linux-2.4.patch">kernel patch</A> and
a couple of user-land utilities dubbed as <A
HREF="tools/">dvd+rw-tools</A>.
<P><TABLE BORDER="0" ALIGN="LEFT">
<TR VALIGN="TOP" ALIGN="JUSTIFY">
<TD><FONT SIZE="-1"><SUP>(*)</SUP></FONT>
<TD><FONT SIZE="-1">Though it doesn't mean that you can't burn
DVD-Video disks with dvd+rw-tools. [Unlike Video-CD] DVD-Video
is "moulded" in oridnary data filesystem and
therefore no explicit support by the burning program is
actually required. In other words it is the DVD-Video
<I>content preparation</I> which is beyond the scope of this
page.</FONT></TR>
</TABLE>
</TR>
</TABLE>
<P><TABLE CELLPADDING=4>
<TR VALIGN="top" ALIGN="justify">
<TH>Q. <TH ALIGN="left">Kernel patch? This sounds too complicated
already! Can't I just use <A
HREF="http://www.fokus.fhg.de/research/cc/glone/employees/joerg.schilling/private/cdrecord.html">cdrecord</A>
or something similar?
</TR>
<TR VALIGN="top" ALIGN="justify">
<TD>A. <TD>As for cdrecord[<A
HREF="ftp://ftp.berlios.de/pub/cdrecord/ProDVD/">-ProDVD</A>].
DVD+RW/+R recording strategy is somewhat different from one
supported by cdrecord, so it simply doesn't work (nor do <A
HREF="http://www.freesoftware.fsf.org/dvdrtools/">dvdrtools</A>
despite what <A
HREF="http://www.redhat.com/docs/manuals/linux/RHL-7.3-Manual/release-notes/x86/">RedHat
7.3 Release Notes</A> say). But do you <I>have to</I> apply the
kernel patch? It should be explicitly noted that the user-land
utilities, dvd+rw-tools, do provide for burning of DVD+RW/+R
<B>without</B> explicit kernel support. So that if <A
HREF="#tutorial">they</A> fullfill your requirements, <I>then</I>
patching the kernel is by all means optional.</TR>
</TABLE>
<P><TABLE CELLPADDING=4>
<TR VALIGN="top" ALIGN="justify">
<TH>Q. <TH ALIGN="left">What is the kernel patch good for then?
</TR>
<TR VALIGN="top" ALIGN="justify">
<TD>A. <TD>DVD+RW (but not DVD+R) is a true random write access media
and therefore is suitable for housing of arbitrary filesystem,
e.g. udf, vfat, ext2, etc. This, and this alone, qualifies
DVD+RW support for kernel implementation. <I>However!</I> I
have to recommend to <B>deploy it with caution</B>, see <A
HREF="#udf">tutorial</A> for further details. Then support for
arbitrary filesystem usfotunately doesn't seem to work with 1st
generation drives, Ricoh MP5120A and derivatives (see Technical
Ramblings below for further details).
</TABLE>
<P><TABLE CELLPADDING=4>
<TR VALIGN="top" ALIGN="justify">
<TH>Q. <TH ALIGN="left">What are the dvd+rw-tools for?</TR>
<TR VALIGN="top" ALIGN="justify">
<TD>A. <TD>As already implied/mentioned to master the DVD+RW/+R media
with<TT>:-)</TT> I could simply refer you to the tutorial, but
figured that couple of words about the [original] design ideas
behind <B><A HREF="#growisofs">growisofs</A>, the principal
burning utility</B>, wouldn't harm. Even though modified kernel
can let you put for example an ext2 filesystem on DVD+RW, it's
probably not very practical, because you most likely want to
access the data on <I>arbitrary</I> computer. Or in other words
you most likely want ISO9660. Trouble is that you might as well
want to <I>add</I> data now and then. And what options do you
have in the lack of multiple sessions (yes, DVD+RW has no
notion of multiple sessions)? Complete remastering which takes
more and more time as dataset grows? Well, yes, <B>unless</B>
you employ growisofs! growisofs provides the way to both lay
down <I>and</I> grow an ISO9660 filesystem on (as well as to
burn an arbitrary pre-mastered image to) both DVD+RW and DVD+R
media.</TR>
</TABLE>
<P><TABLE CELLPADDING=4>
<TR VALIGN="top" ALIGN="justify">
<TH>Q. <TH ALIGN="left">Do I still need <A
HREF="http://www.fokus.fhg.de/research/cc/glone/employees/joerg.schilling/private/cdrecord.html">cdrtools</A>?
</TR>
<TR VALIGN="top" ALIGN="justify">
<TD>A. <TD>Yes. It should be explicitly noted that growisofs is a
front-end to mkisofs, i.e. invokes mkisofs to perform the
actual ISO9660 filesystem layout. Secondly, the DVD+RW drives
available on the market can burn even CD-R[W] media and
cdrecord is the tool for this job [and this job only].</TR>
</TABLE>
<P><TABLE CELLPADDING=4>
<TR VALIGN="top" ALIGN="justify">
<TH>Q. <TH ALIGN="left">There're dual-format DVD+RW/-RW units
available on the market, e.g. SONY DRU500. Can I use
dvd+rw-tools with it/them?
</TR>
<TR VALIGN="top" ALIGN="justify">
<TD>A. <TD>If the question is if you can use dvd+rw-tools to master the
DVD+RW/+R media in a ±RW drive, then the answer always
was "definitely yes." If the question really is if
you can use dvd+rw-tools to burn even DVD-R[W] media, then I
have the pleasure to inform you that as of version 5.0
dvd+rw-tools provide <I>experimental</I> support even for
recording of DVD-R[W] media and refer you to <A HREF="-RW/">a
dedicated page</A> for futher details.</TR>
</TABLE>
<P><HR>
<H3>Foreword/Disclaimer</H3>
<P ALIGN="JUSTIFY">Given the absolute lack of [initial] support from
vendor(s) you should consider this page to be a result of guesswork.
There still is a couple of fatal failures indicated by vendor-specific
error codes (see Technical Ramblings) and I didn't <I>yet</I> figured
out the way around them. So the status of this "project" is
rather "gathering experience" than "ready for production
environment."
<P ALIGN="JUSTIFY">If you have submitted a problem report and haven't
heard from me within 4-5 working days, then you most likely overlooked
something on the page. Please read it more attentively...
<A NAME="tutorial"><P><HR></A>
<H3>Tutorial</H3>
<P><HR WIDTH="50%" ALIGN="LEFT">
<UL>
<P><LI><P ALIGN="JUSTIFY">If you have an IDE unit, make sure it is
"routed" through ide-scsi emulation layer by either:
<P><UL>
<LI>passing "<TT>hd<FONT COLOR="red">X</FONT>=ide-scsi</TT>"
argument to kernel;
<LI>appending following lines to your /etc/modules.conf:
<BLOCKQUOTE>
<PRE>options ide-cd ignore=hd<FONT COLOR="red">X</FONT>
pre-install sg modprobe ide-scsi
pre-install sr_mod modprobe ide-scsi
pre-install ide-scsi modprobe ide-cd
</PRE></BLOCKQUOTE>
</UL>
<P ALIGN="JUSTIFY">Keep in mind that once hd<FONT COLOR="red">X</FONT>
is routed through ide-scsi, you can no longer refer to <TT>/dev/hd<FONT
COLOR="red">X</FONT></TT>, but to corresponding <TT>/dev/scd<FONT
COLOR="red">N</FONT></TT> only.
<P><LI><P ALIGN="JUSTIFY">If you have an external unit, just get it
working as CD-ROM first. I myself have no personal experience
whatsoever with <A HREF="http://www.linux-usb.org/">USB</A> or <A
HREF="http://www.linux1394.org/">IEEE1394/Firewire</A> storage
devices of any kind and have to direct you elsewhere for specific
instructions. I however am confident that if you manage to get your
drive working <I>reliably</I> as CD-ROM <I>and</I> CD-R[W] burner, then
you won't have any troubles with DVD+RW part. As for the moment of this
writing, USB connected drives were reported to be working fine.
Firewire connected drives in turn were reported to fail miserably under
2.4.18. The failure didn't seem to be DVD+RW related as it reportedly
failed burning even CD-R media. Firewire support was substantially
revamped in 2.4.19, and <A HREF="tools/">dvd+rw-tools</A> were reported
to work with this kernel.
<P><LI><P ALIGN="JUSTIFY">If you're running 2.4.19 or .20, consider
applying <A HREF="sg-2.4.19.patch">this drivers/scsi/sg.c patch</A>. I
write "consider" and not "do" for the following
reasons:
<UL>
<LI>dvd+rw-tools are not affected by this bug (as they don't use sg
interface), cdrecord is;
<LI>I however haven't actually experienced the problem with cdrecord
(maybe yet, kernel could have managed to keep buffers neatly aligned
while talking to cdrecord those times I tried), it was VMware that has
failed miserably on me;
</UL>
<P><LI><P ALIGN="JUSTIFY">Download, unpack and compile the <A
HREF="tools/">the toolchain</A>. Note that separate source code files
found in the <A HREF="tools/">download catalog</A> are provided mainly
for references purposes. To build the thing do pick the .tar.gz
archive, which contains Makefile as well as .spec file.
<P><LI><P ALIGN="JUSTIFY">If you have 1st generation drive (Ricoh
MP5120A and derivatives) do consider upgrading your firmware (see <A
HREF="http://ext.ricoh.co.jp/dvd/asia/support/download/mp5120a/">Ricoh</A>,
<A
HREF="http://www.hp.com/cposupport/swindexes/hpdvdwrite81685_swen.html">HP</A>,
<A
HREF="http://www.met.com.tw/eng/support/download/cdrw/oem/rw5120a.htm">MET</A>
pages). Fixed bug descriptions are vague, but at the very least after
upgrade to 1.34 I could no longer reproduce infrequent "random
positioning errors" when <B>reading</B> a file system with a lot
of small files. 1.34 adds support for Verbatim media and 1.37
apparently for Memorex. Version 1.37 also implements a secret
vendor-specific command which <A HREF="#booktype">reportedly improves
compatibility</A> with a number of DVD-ROM drives (more about this
matter in Technical Ramblings). <!--So for whatever it's worth do
consider upgrading...-->
<P ALIGN="JUSTIFY">Several 2nd generation unit (Ricoh MP5125A and
derivatives) users have reported that their systems lock up the while
recording DVD+R, but not DVD+RW. I myself have never experienced
anything similar, but firmware upgrade did help those who has suffered
from this. So that apparently even 2nd generation users should
be considering firmware upgrade.
<P><LI><P ALIGN="JUSTIFY">Formatting the DVD+RW media. Just pass the
device name, e.g. <TT>/dev/scd0</TT>, as an argument to <A
HREF="tools/dvd+rw-format.cpp">dvd+rw-format</A>. To make formatting
process reasonably fast the media gets formatted only partially, as you
can notice by observing a progress indicator displayed by the program.
The final indicator value varies from firmware to firmware, values as
low as 1.6% were observed. But it does not mean that you can only write
that little. The unit keeps formatting <I>transparently</I>, as you add
more data. Oh! Do keep in mind that DVD capacity of 4.7GB are
salesman's GB, i.e. 1000<SUP>3</SUP> and not 1024<SUP>3</SUP>.
<P ALIGN="JUSTIFY">It was observed that excessive reformats can render
media unusable already after 10-20 reformats and [enforced] reformat is
therefore not recommended. As you might remember former
recommendatations for reformatting were for privacy reason. Version 2.x
is not suitable for this purpose, because so called
"immediate" form (first utilized in version 2.0) of the
"FORMAT UNIT" command does not attempt to zero all the data
written so far. If you are concerned about privacy, nullify explicitely
with '<TT>growisofs -Z /dev/scd<FONT
COLOR="red">N</FONT>=/dev/zero</TT>' (or '<TT>dd if=/dev/zero
of=/dev/scd<FONT COLOR="red">N</FONT> bs=32k</TT>' if you've patched
the kernel and like dd better<TT>:-)</TT>.
<P ALIGN="JUSTIFY">DVD+R media does not require any formatting
procedure applied and is ready to use out-of-the-box. Apparently, a
reminder that 1st generation units (Ricoh MP5120A and derivatives)
are not capable of burning DVD+R is needed.
<A NAME="growisofs"><P></A><LI><P ALIGN="JUSTIFY">Burning with <A
HREF="tools/growisofs.c">growisofs</A>. There is no manual for
growisofs as there is very little need for one. In a nutshell growisofs
just passes all command line arguments to mkisofs and dumps its output
directly onto the media. The first part means that you basically can
[well, <I>should</I>] consult <A HREF="mkisofs.8.html">mkisofs manual
page</A> and accompanying reference documention (including multisession
related section[s]) and the second part means that you shouldn't expect
an ISO-image on the standard output (nor make sure you have enough free
temporary storage<TT>:-)</TT>. Differences from mkisofs command line
are:
<P><UL>
<LI>you may not use -o option;
<LI>you don't have to specify -C option, growisofs will construct one
for you;
<LI>there is internal -Z option for initial session "burning,"
this implements formerly suggested 'mkisofs | dd of=/dev/scd0';
</UL>
<P ALIGN="JUSTIFY">Otherwise <I>everything</I> that applies to
[multisession] mastering with mkisofs applies to growisofs as well. For
example just like with mkisofs you should make a note on which options
you used to master the initial "session" with and stick to
them, e.g.:
<P><BLOCKQUOTE><PRE>
growisofs -Z /dev/scd0 <FONT COLOR="red">-R -J</FONT> /some/files
growisofs -M /dev/scd0 <FONT COLOR="red">-R -J</FONT> /more/files
</PRE></BLOCKQUOTE>
<P ALIGN="JUSTIFY">Oh! Do make sure you have at least mkisofs <FONT
COLOR="red">1.14</FONT> on your $PATH (mkisofs 1.14 is part of cdrtools
1.10).
<P ALIGN="JUSTIFY"><B>In addition</B>, growisofs [version 3.3 or later]
recognizes special form of -Z command line option which permits burning
of arbitrary pre-mastered images. The "magic" command is:
<P><BLOCKQUOTE><PRE>
growisofs -Z /dev/scd0<FONT COLOR="red">=</FONT>image.iso
</PRE></BLOCKQUOTE>
<P ALIGN="JUSTIFY">where <TT>image.iso</TT> represents an arbitrary
object in the filesystem, such as file, named pipe or device entry. No,
nothing is growing here and command name is counter-intuitive in this
particular context. And here is even less intuitive<TT>:-)</TT> If you
want to burn output generated by an arbitrary program, you can use:
<P><BLOCKQUOTE><PRE>
dumpsomething | growisofs -Z /dev/scd0=<FONT COLOR="red">/dev/fd/0</FONT>
</PRE></BLOCKQUOTE>
<P ALIGN="JUSTIFY">Burning DVD+R implies extra limitations:
<P><UL>
<LI>Needless to say that you have only one shot with -Z
option<TT>:-)</TT>
<LI>Apparently media needs to be manually reloaded [ejected and pushed
back again] after every burning session (well, if you haven't patched
the kernel that is<TT>:-)</TT>
<LI>Unlike DVD+RW DVD+R media does have notion of multiple sessions.
<I>However!</I> DVD-ROM drives can only "see" the first one.
DVD+R burners will be the only ones capable to access the files added
at different occasions.
<LI>Even though DVD+R unit does "sense" multiple sessions,
Linux sometimes fails to pull that information from the
drive<TT>:-(</TT> Till the problem is looked into and resolved you can
work it around by reloading driver with '<TT>rmmod sr_mod</TT>'.
<LI>If you go for multisession anyway, you have to use mkisofs from <A
HREF="ftp://ftp.berlios.de/pub/cdrecord/">cdrtools-2.0 or later</A> or
apply <A HREF="multi.diff">this patch</A>.
</UL>
<P ALIGN="justify">And once again, do keep in mind that 4.7GB are
salesmen's GB, i.e. 1000<SUP>3</SUP> and not 1024<SUP>3</SUP>. If
translated to "real" GB, DVD+R[W] capacity is not larger
than 4.4GB! It should also be noted that earlier growisofs versions did
not check if there is enough space on media to accomodate the data-set
to be burned, meaning that it was your responsibility to make sure
"overburn" condition is not raised. As of version 5.2
growisofs performs the necessary checks for you and refuses to start
recording if "overburn" condition appears to be unavoidable.
This behaviour can be overriden with <TT>-overburn</TT> command-line
option.
<P><LI><P ALIGN="justify">If you're satisfied with growisofs, then you
should just proceed to <A HREF="#compat">the next chapter</A> and
abstain from applying the <B>optional</B> kernel patch. If you haven't
stopped reading beyond this line, <A
HREF="linux-2.4.patch">download</A> the patch, apply it, rebuild the
kernel or modules and re-install (kernel or cdrom.o and sr_mod.o
modules, whichever appropriate), but don't ask <I>me</I> <A
HREF="http://www.linuxhq.com/patch-howto.html">how</A>. To see it in
action, insert formatted DVD+RW media and try to access it, '<TT>dd
if=/dev/scd<FONT COLOR="red">N</FONT> count=0</TT>' would do. Then
verify that kernel logs "<TT>sr<FONT COLOR="red">N</FONT>: mmc-3
profile: 1Ah</TT>". You should now be able to '<TT>mkisofs -pad . |
dd of=/dev/scd<FONT COLOR="red">N</FONT> obs=32k</TT>' or even
'<TT>mke2fs -b 2048 /dev/scd<FONT COLOR="red">N</FONT></TT>' and
observe kernel logging "<TT>sr<FONT COLOR="red">N</FONT>: dirty
DVD+RW media</TT>."
<P ALIGN="justify">If you have previous patch version applied, then you
have to back it out first. The simplest way is probably to restore
<TT>drivers/scsi/sr*.[ch]</TT> and <TT>drivers/cdrom/cdrom.c</TT> from
your original Linux source code ditribution.
<A NAME="udf"><P><LI></A><P ALIGN="justify">Even though kernel now
permits to build and mount arbitrary filesystem, there is one thing you
<I>must</I> keep in mind before you just proceed, no matter how
tempting it might appear.
<P ALIGN="justify">As you might know DVD+RW media can sustain only
around 1000 overwrites. Now the thing about fully fledged filesystems
is that every read [or tight bunch of 'em] is accompanied by
corresponding i-node update or in other words a write! Now let's say
you lookup the mount point (e.g. ls /mnt/dvd) ten times a day. This
gives you a 100 days lifetime on your mountpoint and therefore media.
Not really much, huh? So do use <TT>noatime</TT> mount option with
DVD+RW media or have it mounted read-only most of the time. However!
Every read-write mount "costs" a super-block update. So that
if you remount the media say 3 times a day, it would last for about a
year [<A
HREF="http://people.mandrakesoft.com/~quintela/supermount/">supermount</A>
would exhaust the "budget" way sooner]... Defect management
[in firmware, a.k.a. <A
HREF="http://www.licensing.philips.com/information/mtr/">Mt.Rainier</A>,
or at filesystem level] would improve the situation, but ideally
filesystem driver should definitely refrain from modifying the
superblock [marking it dirty] if nothing was actually written since
last mount. Given the development status of <A
HREF="http://sourceforge.net/projects/linux-udf/">Linux UDF</A> the
chances for seeing the latter implemented [for UDF] are more than just
conceivable. The request is already filed and even possible solution is
being discussed. But why not give UDF a shot already then? By default
UDF write support is unfortunately disabled and you might have to
reconfigure the kernel and rebuild modules. Alternatively [my preferred
option actually] fetch the code at <A
HREF="http://sourceforge.net/projects/linux-udf/">SourceForge</A> and
build the module separately. Of course you will have to fetch and build
udftools as well. But once it's done just type:
<P><BLOCKQUOTE><PRE>
mkudffs --spartable=2 --media-type=cdrw /dev/scd<FONT COLOR="red">N</FONT>
mount -o rw,noatime /dev/scd<FONT COLOR="red">N</FONT> /mnt/cdrom
</PRE></BLOCKQUOTE>
<P ALIGN="JUSTIFY"><TT>mkudffs</TT> command line options were suggested
by UDF maintainer, Ben Fennema.
<P><LI><P ALIGN="JUSTIFY">Performance optimizations. This paragraph
applies only if you've patched the kernel. As some of you might
remember the original recommendation was "do use <TT>obs=32k</TT>
for optimal performance." Well, it was rather naive of me to say
so, as common block device layer <I>completely</I> reorganizes the
stream so that '<TT>>/dev/scd0</TT>' is as good as '<TT>|dd
of=/dev/scd0 obs=32k</TT>'. It should also be noted that dumping to
/dev/scd0 puts quite a pressure on VM subsystem, as the data passes
through block buffer cache. To minimize the pressure and improve
overall system performance bind the cdrom device to a raw device, e.g.
'<TT>raw /dev/raw/raw1 /dev/scd0</TT>', growisofs will locate and use
it automatically. obs=32k makes perfect sense with /dev/raw devices,
but dd won't work as /dev/raw expects specifically aligned buffer...
Good news are that <A
HREF="ftp://ftp.berlios.de/pub/sdd/">sdd</A> aligns the transfer
buffer so that if you've got an image to burn down (or want to nullify)
stick to '<TT>sdd of=/dev/raw/raw<FONT COLOR="red">X</FONT> obs=32k
...</TT>'
</UL>
<A NAME="compat"><P><HR></A>
<H3>Compatibility: caveat lector</H3>
<P><HR WIDTH="50%" ALIGN="LEFT">
<P ALIGN="JUSTIFY">In order to optimize seek times DVD[-ROM] players
calibrate their mechanics every time the media is loaded by sliding
the optical head some place, picking up the signal and noting the
physical block address underneath the lens. In order for this procedure
to work with rewritable/recordable media, that particular spot has to
be written to [or de-iced in DVD+RW case]. Some units slide the head to
30mm [radial] to calibrate, some to 35mm. In order to keep such players
"happy," make sure that at least 1GB is written.
<P ALIGN="JUSTIFY">Other units attempt to seek to lead-out [or vicinity
of it] for calibration purposes. Now the catch is that it's perfectly
possible to produce a DVD+RW disk without lead-out. Most notably media
initially formatted with dvd+rw-format [apparently] doesn't have any
lead-out, not to mention that practically whole surface remains virgin.
If you fail to mount/play DVD+RW media, attempt to
<BLOCKQUOTE><PRE>dvd+rw-format -lead-out /dev/scd<FONT
COLOR="red">N</FONT></PRE></BLOCKQUOTE>
<P ALIGN="JUSTIFY">which relocates the lead-out next to outermost
written sector as well as makes sure there is no virgin surface before
it. Previously written data should <B>not</B> be affected by this
operation. "Should" is a reminder of the project status,
"experience gathering." I mean the best I can do is to state
that my hp dvd200i unit doesn't wipe any data when relocating the
lead-out.
<P ALIGN="JUSTIFY">Then non-finalized DVD+R disks don't have lead-out
either<SUP>(*)</SUP>. If you fail to mount/play DVD+R media and wish to
sacrifice the remaining space for immediate compatibility, just fill
the media up<SUP>(**)</SUP>. Alternatively if you master DVD+R disc in
a single take and don't plan to use it for
multi-sessioning<SUP>(***)</SUP>, you have the option to invoke
growisofs with <TT>-dvd-compat</TT> option and cut the real lead-out
directly after the first session.
<P>
<TABLE BORDER="0" WIDTH="95%" ALIGN="CENTER">
<TR VALIGN="TOP" ALIGN="JUSTIFY">
<TD><FONT SIZE="-1"><SUP>(*)</SUP></FONT>
<TD><FONT SIZE="-1">Well, there are lead-outs at the session edges, but
the problem is that "End Physical Sector Number of Data Area"
field in "Control Data Zone" of the lead-in contains address
of the largest media sector, which makes affected DVD[-ROM] players
calibrate at the outermost edge instead of the first session. Actually
I fail to understand why don't they burn the address of last sector of
the first session in the lead-in even on multi-session disks? Something
to correct in next firmware update?
</FONT></TR>
<TR VALIGN="TOP" ALIGN="JUSTIFY">
<TD><FONT SIZE="-1"><SUP>(**)</SUP></FONT>
<TD><FONT SIZE="-1">The easiest way is to create couple of holey files
with '<TT>touch huge<FONT COLOR="red">M</FONT>.void</TT>' and '<TT>perl
-e 'truncate ("huge<FONT COLOR="red">M</FONT>.void",
0x7ffffffe)'</TT>', and finally to '<TT>growisofs -M /dev/scd<FONT
COLOR="red">N</FONT> ... huge*.void</TT>'.
The command is bound to fail with "end of medium reached,"
but that's what you basically want.</FONT></TR>
<TR VALIGN="TOP" ALIGN="JUSTIFY">
<TD><FONT SIZE="-1"><SUP>(***)</SUP></FONT>
<TD><FONT SIZE="-1">E.g. when mastering DVD-Video disk:-) Note that
<TT>-dvd-video</TT> option [passed to mkisofs] engages
<TT>-dvd-compat</TT> automatically.</FONT></TR>
</TABLE>
<A NAME="booktype"><P><HR WIDTH="50%" ALIGN="LEFT"></A>
<P ALIGN="JUSTIFY">Then we have logical format compatibility
issue(s). Probably the very ground for all the controversy around
DVD+RW, rather around DVD+RW media not being playable in a whole range
of players. DVD+RW Alliance was keen to blame on DVD-ROM vendors, even
claiming that they deliberately block playback. But the fact is that
format specifications don't explicitely say that unrecognized format
[designated by "Book Type" field in "Control Data
Zone" of the lead-in] should be treated as DVD-ROM and [in my
opinion] it was rather naive of them to claim and expect that the media
will be playable in "virtually all players." This deficiency
was recognized by practically all DVD+RW vendors [apparently all except
Sony] and a <A HREF="tools/dvd+rw-booktype.cpp">secret</A>
vendor-specific command manipulating this "Book Type" field
was implemented. So if you fail to mount/play DVD+RW media, you have an
option to attempt
<BLOCKQUOTE><PRE>dvd+rw-booktype -dvd-rom -media /dev/scd<FONT
COLOR="red">N</FONT></PRE></BLOCKQUOTE>
<P ALIGN="JUSTIFY">It's naturally not possible to manipulate the
"Book Type" field on DVD+R media, that is not after the
lead-in is written [which takes place at the moment the first session
gets closed]. But it's possible to control how it [lead-in] is going to
be branded by programming the drive <I>in advance</I>:
<BLOCKQUOTE><PRE>dvd+rw-booktype -dvd-rom -unit+r /dev/scd<FONT
COLOR="red">N</FONT></PRE></BLOCKQUOTE>
<P ALIGN="JUSTIFY">Meaning that if you fail to play DVD+R media, you
can attempt to burn another disc with more appropriate unit settings.
For more background information about dvd+rw-booktype, see <A
HREF="http://www.dvdplusrw.org/resources/bitsettings.html">"Compatibility
Bitsettings" article at dvdplusrw.org</A>.
<P ALIGN="JUSTIFY">There [potentially] are other logical
DVD+RW<SUP>(*)</SUP> format incompatibilites, but the "Book
Type" issue discussed above is the only one "officially"
recognized. Well, it's actually understandable as it's the only one
that can be recognized and addressed by a DVD+RW vendor alone.
Recognition of other incompatibilities would require cooperation from
DVD[-ROM] player vendors and that's something they apparently are not
willing to show referring to the fact that DVD+RW format is not
approved [and apprently never will be] by <A
HREF="http://www.dvdforum.org/">DVD Forum</A><SUP>(**)</SUP>.
<P>
<TABLE BORDER="0" WIDTH="95%" ALIGN="CENTER">
<TR VALIGN="TOP" ALIGN="JUSTIFY">
<TD><FONT SIZE="-1"><SUP>(*)</SUP></FONT>
<TD><FONT SIZE="-1">Finalized DVD+R media branded with DVD-ROM
"Book Type" is virtually identical to DVD-ROM.</FONT></TR>
<TR VALIGN="TOP" ALIGN="JUSTIFY">
<TD><FONT SIZE="-1"><SUP>(**)</SUP></FONT>
<TD><FONT SIZE="-1">To which I say "so what?" DVD Forum is an
alliance of manufacturers just like DVD+RW Alliance is. It [or any
other party for that matter] has no authority to deny a technology
development initiative.</FONT></TR>
</TABLE>
<P><HR WIDTH="50%" ALIGN="LEFT">
<P ALIGN="JUSTIFY">Finally there is a physical incompatibility issue.
They claim that there're optical pick-ups out there not being capable
to decode the track because of low reflectivity of DVD+RW media
surface. I write "they claim," because in the lack of
cooperation from DVD[-ROM] vendors it's not possible to distinguish
physical from logical format incompatibility, which I find important to
tell apart in order to make sure at least logical format
incompatibility issues don't persist over time. It might be as trivial
as following. As you surely know [already], DVD+RW has same
reflectivity as dual-layer DVD-ROM. Now the catch is that the linear
pit density in turn is same as of single-layer one. Meaning that if
player makes assumptions about linear pit density based on
reflectivity, then it won't be able to trace the track... But either
way, there is very little you can do about this one, but to try another
player...
<P><HR>
<H3>Technical Ramblings</H3>
<P><HR WIDTH="50%" ALIGN="LEFT">
<P ALIGN="JUSTIFY">What does "DVD+RW support" <I>really</I>
mean? Even though DVD+RW has no notion of [multiple] sessions, to
ensure compatibility with DVD-ROM it's essential to issue "CLOSE
TRACK/SESSION (5Bh)" <A
HREF="http://www.t10.org/scsi-3.htm">MMC</A> command to
terminate/suspend background formatting (if any in progress) whenever
you intend to eject the media or simply stop writing and want better
read performance (e.g. remount filesystem read-only). This is what the
patch is basically about: noting when/if media was written to and
"finalizing" at unlock door.
<P ALIGN="JUSTIFY">Secondly, whenever you employ fully fledged file
system, I/O requests get inevitably fragmented. "Fragmented"
means following. Even though you can address the data with 2KB
granularity, it [data] is physically laid out in 32KB chunks. This in
turn means that for example writing of 2KB block involves reading of
32KB chunk, replacing corresponding 2KB and writing down of modified
32KB chunk. "Fragmented requests" are those that are smaller
than 32KB or/and cross the modulus 32KB boundaries. In order to
optimize the process certain caching algorithm is implemented in unit's
firmware. Obviously it can't adequately meet all possible situations.
And so in such unfortunate situations the drive apparently stops
processing I/O requests returning "COMMAND SEQUENSE ERROR
(2Ch)" ASC. This is the second essential of "DVD+RW
support," namely injecting of "SYNCHRONIZE CACHE (35h)"
MMC command in reply to the error condition in question. The command
flushes the cached buffers which makes it possible to resume the data
flow.
<P ALIGN="JUSTIFY"><B>Unfortunately</B> the above paragraph doesn't
seem to apply to the 1st generation drives, Ricoh MP5120A and
derivatives<TT>:-(</TT> "SYNCHRONIZE CACHE (35h)" doesn't
seem to be sufficient and the unit keeps replying with "COMMAND
SEQUENSE ERROR (2Ch)" going into end-less loop. This makes it
impossible to deploy arbitrary file system. I'm open for
suggestions... Meanwhile the I've chosen to simply suspend I/O till the
media is unmounted.
<P ALIGN="JUSTIFY">Even 2nd gen unit were reported to exhibit similar
[but not the same] behaviour under apparently extremely rare
circumstanses. At least I failed to reproduce the problem... But it's
being looked into...
<P ALIGN="JUSTIFY">This one really beats me. Sometimes the unit
simply stops writing signalling a vendor specific positioning error,
03h/15h/82h to be specific. Especially if the media is newly formatted.
Couple of work theories. One is that block buffer cache reorders
requests so that they are not sequential anymore, "FLUSH
CACHE" might do the trick. Another one is that under
"underrun" condition background formatting kicks off and has
to be explicitely stopped. "Underrun" is in quotes because
the unit is supposed to handle temporary data stream outages
gracefully. If you run into this (you most likely will), try to
complement growisofs command line with [undocumented]
<TT>-poor-man</TT> option (which has to be first in the command line).
This option eliminates request reorders and minimizes possibility for
"underrun" condition (by releasing the pressure off VM
subsystem).
<P ALIGN="JUSTIFY">The original idea was to implement DVD+RW support in
drivers/cdrom/cdrom.c. Unfortunately SCSI layer maintains private
"writeable" flag controlling the ability to issue WRITE
commands. The flag is impossible to reach for from the Unified CD-ROM
driver. But why am I talking about SCSI when there are only IDE units
out there (at least for the time being)? Well, as you most likely want
to occasionally burn even CD-R[W] with cdrecord you want it to go
through ide-scsi emulation layer anyway. So I figured that SCSI CD-ROM
driver is the one to aim for even for DVD+RW.
<P ALIGN="JUSTIFY">Unfortunately it was not possible to implement it
completely in sr_mod.o<TT>:-(</TT> Minor drivers/cdrom/cdrom.c
modification was required to sense the media before decision about
whether or not to permit write open. That's because DVD+RW drives are
morphing their behaviour after currently mounted media and it's
essential to identify newly inserted media.
<P ALIGN="JUSTIFY">Special comment about "what a dirty
hack!!!" To my great surprise it turned out that timeout value you
pass in cdrom_generic_command is simply ignored and timeout is set to
precompiled value of 30 seconds. Unfortunately it's way too low for
formatting purposes and I had to do something about it. Alternative to
"the dirty hack" was to add another argument to sr_do_ioct
and modify all the calls to it... I've chosen to take over those 31
unused bits from the "quiet" argument instead of modifying
all the calls (too boring).
<P ALIGN="JUSTIFY">There is another kernel "deficiency" I ran
into while working on the (original version of) dvd+rw-format utility.
The drive provides background formatting progress status, but
unfortunately it's impossible to access it. That's because progress
counter is returned [in reply to "TEST UNIT READY"] as
"NO SENSE/LOGICAL UNIT NOT READY/FORMAT IN PROGRESS" sense
bytes but with "GOOD" status. Apparently any sense data with
"GOOD" status is discarded by the common SCSI layer.
<!--
<P ALIGN="JUSTIFY">As you might have noticed the timeout value for
"CLOSE SESSION" is 3000 seconds. Does it really take that
long? It might... Disappointed? Don't be! It might happen <I>only</I>
when <I>reformatting</I> used media. Formatting of the <I>blank</I>
media doesn't take longer than a couple of minutes. <I>Reformatting</I>
in turn takes as long as it takes to nullify whatever you had on the
media which requires corresponding timeouts. But do you <I>have to</I>
reformat? Well, only if media contains sensitive data, the new dataset
is smaller than the current one and (for some reason) will be easier
for potentially rival party to get hold of it (in other words when
there is a risk for sensitive data to get exposed). Another reason is
when you want to reuse the media as a master copy for DVD-ROM
manufacturing and want formatted capacity to reflect dataset size.
Otherwise there is <I>no</I> reason to reformat and as long as you
don't you won't be disappointed with how long does it take to
"finalize" the media.
-->
<P ALIGN="JUSTIFY">It was pointed out to me that DVD+RW units work with
Acard <A HREF="http://www.acard.com/eng/product/scside.html">SCSI to
IDE bridges</A>.
<A NAME="plusvsminus"><P><HR WIDTH="50%" ALIGN="LEFT"></A>
<P ALIGN="JUSTIFY">What does <I>plus</I> in DVD+RW/+R stand for?
Originally this paragraph started as following:
<BLOCKQUOTE><P ALIGN="JUSTIFY">The key feature of DVD+RW/+R media is
high [spatial] frequency wobbled [pre-]groove with addressing
information modulated into it. This makes it possible to resume
interrupted [or deliberately suspended] burning process with accuracy
high enough for DVD[-ROM] player not to "notice" anything at
playback time. Recovery from buffer underrun condition in DVD-RW/-R
case in turn is way less accurate procedure, and the problem is that
the provided accuracy is very much what average player can tolerate.
Now given that both provided and tolerated inaccuracies are
proportional to respectively writing and reading velocities there
basically no guarantee that DVD-RW/-R recording that suffered from
buffer underrun will be <I>universally</I> playable.</BLOCKQUOTE>
<P ALIGN="JUSTIFY">Well, it turned out that I was wrong about one
thing. <!--About projecting CD-R[W] buffer underrun recovery procedure
to DVD-R[W] to be specific.--> I failed to recognize that DVD-R[W]
groove also provides for <I>adequately</I> accurate recovery from
buffer underrun condition/lossless linking. Not as accurate as DVD+RW,
but accurate enough for splices to be playable in virtually any
DVD-ROM/-Video unit. However! When it comes to DVD-R[W] recording you
apparently have to choose<SUP>(*)</SUP> between
<UL>
<LI>buffer underrun protection and
<LI>full DVD-ROM/-Video compatibility.
</UL>
<P ALIGN="JUSTIFY">The catch is that the latter is achieved only in
Disk-at-once Recording mode which requires: a) prior knowledge of
data-set size, b) uninterrupted data-stream (buffer underruns are not
tolerated). While the former is defined only in Incremental Recording
mode which implies explicit support by player unit<SUP>(**)</SUP>.
DVD+RW/+R in turn is free from this limitation and combine
DVD-ROM/-Video compatibility with <I>unconditional</I> buffer underrun
protection.
<P ALIGN="JUSTIFY">As already mentioned, DVD+RW groove has
"addressing information modulated into it." This gives you an
advantage of writing in truly arbitrary order, even to virgin surface
and practically instantly (after ~40 seconds long initial format
procedure). In addition DVD+RW can be conveniently written with 2KB
granularity<SUP>(***)</SUP>. DVD-RW in turn can only be
<I>overwritten</I> in arbitrary order. Meaning that it either has to be
completely formatted first (it takes an hour to format 1x media), or
initially written to in a sequential manner. And it should also be
noted that arbitrary overwrite is <I>never</I> an option if DVD-RW
media was recorded in compatible Disc-at-once mode, whole disc blanking
is.
<P ALIGN="JUSTIFY">What does all of the above mean in practice? Well, I
was actually hoping that readers would [be able to] figure it out by
themselves. Apparently a couple of "guiding" words are
needed... It means that it's trivial to employ DVD+RW for housing of
live and arbitrary filesystem, no special modifications to target
filesystem driver are [normally] required. Consequently real-time VBR
(Variable Bit Rate) Video recording is a children's game.
<P ALIGN="JUSTIFY">Sometimes DVD+RW/+R recording strategy is referred
to as packet writing. I myself am reluctant to call it so (or
TAO/SAO/DAO) for the following reason. Despite the fact that DVD-R[W]
provides for lossless linking (within a packet/extent only),
packets/extents are still denoted with certain linking information
which distinguishes it (recording mode in question) from e.g.
Disk-at-once. Now the point is that written DVD+RW/+R media, rather its
Data Zone, does not contain <I>any</I> linking information and is
logically indistinguishable from one written in DVD-R[W] Disc-at-once
mode (or DVD-ROM for that matter).
<P ALIGN="JUSTIFY">It's claimed that signal from DVD+RW groove (the one
essential for recording, not reading) is much stronger which makes it
quite resistant to dust, scratches, etc.
<P>
<TABLE BORDER="0" WIDTH="95%" ALIGN="CENTER">
<TR VALIGN="TOP" ALIGN="JUSTIFY">
<TD><FONT SIZE="-1"><SUP>(*)</SUP></FONT>
<TD><FONT SIZE="-1">As specified in <A
HREF="ftp://ftp.avc-pioneer.com/Mtfuji5/Spec/">Mt. Fuji draft</A>. Note
that this document also discusses DVD+RW. You should be aware that they
refer to abandoned version which has very little to do with DVD+RW/+R
implementation being discussed here.</FONT></TR>
<TR VALIGN="TOP" ALIGN="JUSTIFY">
<TD><FONT SIZE="-1"><SUP>(**)</SUP></FONT>
<TD><FONT SIZE="-1">I'm no longer 100% sure that explicit support is
<I>absolutely</I> required... At least linking sectors [if any] are
assigned with Logical Block Address so that address space remains
contiguous... Meaning that it should be sufficient to lay the
filesystem so to say around those holes/linking areas so that player is
never asked to actually play them...</FONT></TR>
<TR VALIGN="TOP" ALIGN="JUSTIFY">
<TR VALIGN="TOP" ALIGN="JUSTIFY">
<TD><FONT SIZE="-1"><SUP>(***)</SUP></FONT>
<TD><FONT SIZE="-1">DVD "native" blocksize is 32KB, and 2KB
granularity is nothing but a trick, but you're excused from playing it,
i.e. reading 32KB, replacing corresponding 2KB and writing 32KB
back.</FONT></TR>
</TABLE>
<P><HR>
<SPACER TYPE="block" WIDTH="100%" HEIGHT="100%">
</BODY>
</HTML>
