|
 |
0e076f |
<HTML>
|
|
|
0e076f |
|
|
|
0e076f |
<HEAD>
|
|
|
0e076f |
<BASE HREF="http://fy.chalmers.se/~appro/linux/DVD+RW/">
|
|
|
0e076f |
<TITLE>Blu-ray Disc/DVD+RW/+R/-R[W] for Linux</TITLE>
|
|
|
0e076f |
|
|
|
0e076f |
dvd+rw, dvd+r, dvdplusrw, dvd-rw, dvd-r, dvd-ram,
|
|
|
0e076f |
dvd+r double layer, dvd+r dl, dvd-r dl,
|
|
|
0e076f |
blu-ray, blu-ray disc, bd, bd-r, bd-re,
|
|
|
0e076f |
linux, netbsd, openbsd, solaris, freebsd, hp-ux, irix, unix,
|
|
|
0e076f |
mac os x, windows, mingw, win32, win64,
|
|
|
0e076f |
hp, ricoh, philips, sony, nec, plextor, benq,
|
|
|
0e076f |
optorite, lite-on, pioneer, lg, panasonic, matshita,
|
|
|
0e076f |
multisession, growisofs">
|
|
|
0e076f |
|
|
|
0e076f |
user-land utilities and optional Linux
|
|
|
0e076f |
kernel patch">
|
|
|
0e076f |
<META HTTP-EQUIV="Content-Type" CONTENT="text/html; charset=iso-8859-1">
|
|
|
0e076f |
<LINK REL="icon" HREF="dvdplusrw.ico" TYPE="image/x-icon">
|
|
|
0e076f |
<LINK REL="shortcut icon" HREF="dvdplusrw.ico" TYPE="image/x-icon">
|
|
|
0e076f |
</HEAD>
|
|
|
0e076f |
|
|
|
0e076f |
|
|
|
0e076f |
LINK="#0000D0" VLINK="#502090" ALINK="#FF0000">
|
|
|
0e076f |
|
|
|
0e076f |
|
|
|
0e076f |
|
|
|
0e076f |
|
|
|
0e076f |
|
|
|
0e076f |
HREF="http://www.dvdrw.com/">DVD+RW/+R/
|
|
|
0e076f |
HREF="-RW/">-R[W] for Linux
|
|
|
0e076f |
by <appro@fy.chalmers.se>,
|
|
|
0e076f |
September 2006
|
|
|
0e076f |
|
|
|
0e076f |
HREF="http://www.ioss.jp/sohodiy/vol02-part01.html">
|
|
|
0e076f |
SRC="japanese.gif" WIDTH=48 HEIGHT=19 BORDER=0 ALT="Japanese">
|
|
|
0e076f |
|
|
|
0e076f |
|
|
|
0e076f |
|
|
|
0e076f |
|
|
|
0e076f |
|
|
|
0e076f |
Q. What is this page (not) about?
|
|
|
0e076f |
|
|
|
0e076f |
A.<SUP> </SUP>
|
|
|
0e076f |
Maybe to your disappointment it is not about
|
|
|
0e076f |
video<SUP>(*)</SUP>. The scope of this page is primarily
|
|
|
0e076f |
computer storage applications of Blu-ray Disc and
|
|
|
0e076f |
DVD±RW/±R, things like backup, archiving, data
|
|
|
0e076f |
exchange... The downloadable files are an optional
|
|
|
0e076f |
HREF="linux-2.4.patch">Linux 2.4 kernel DVD+RW patch and a
|
|
|
0e076f |
couple of user-land utilities dubbed as <NOBR>
|
|
|
0e076f |
HREF="tools/?M=D">dvd+rw-tools</NOBR>.
|
|
|
0e076f |
|
|
|
0e076f |
|
|
|
0e076f |
|
|
|
0e076f |
<FONT SIZE="-1"><SUP>(*)</SUP></FONT>
|
|
|
0e076f |
<FONT SIZE="-1">Though it doesn't mean that you can't burn
|
|
|
0e076f |
DVD-Video discs with dvd+rw-tools. [Unlike Video-CD] DVD-Video
|
|
|
0e076f |
is "molded" in an ordinary data file system and
|
|
|
0e076f |
therefore no explicit support by the burning program is
|
|
|
0e076f |
actually required. In other words it is the DVD-Video
|
|
|
0e076f |
content preparation which is beyond the scope of this
|
|
|
0e076f |
page.</FONT>
|
|
|
0e076f |
|
|
|
0e076f |
|
|
|
0e076f |
|
|
|
0e076f |
|
|
|
0e076f |
|
|
|
0e076f |
|
|
|
0e076f |
Q. Kernel patch? This sounds too complicated
|
|
|
0e076f |
already! Can't I just use [vanilla] cdrecord?
|
|
|
0e076f |
|
|
|
0e076f |
|
|
|
0e076f |
|
|
|
0e076f |
A. It should be explicitly noted that the user-land
|
|
|
0e076f |
utilities, dvd+rw-tools, do suffice for BD/DVD recording
|
|
|
0e076f |
without explicit kernel support. So if they
|
|
|
0e076f |
HREF="#tutorial">fulfill your requirements, then
|
|
|
0e076f |
patching the kernel is by all means optional. As
|
|
|
0e076f |
for [vanilla] cdrecord, non-CD recording strategies are
|
|
|
0e076f |
somewhat different, so it simply doesn't work (nor does
|
|
|
0e076f |
dvdrecord with media other than DVD-R[W], despite what
|
|
|
0e076f |
HREF="http://www.redhat.com/docs/manuals/linux/RHL-7.3-Manual/release-notes/x86/">RedHat
|
|
|
0e076f |
7.3 Release Notes say). On additional note Linux kernel
|
|
|
0e076f |
version 2.6>=10 is equipped with
|
|
|
0e076f |
HREF="http://web.telia.com/~u89404340/packet.html">packet
|
|
|
0e076f |
writing driver which supports even DVD rewritable media,
|
|
|
0e076f |
but I haven't tested it myself, so don't ask:-)
|
|
|
0e076f |
|
|
|
0e076f |
|
|
|
0e076f |
|
|
|
0e076f |
|
|
|
0e076f |
Q. What is the kernel patch good for then?
|
|
|
0e076f |
|
|
|
0e076f |
|
|
|
0e076f |
A. DVD+RW (but not DVD+R nor any DVD-dash) is a true random
|
|
|
0e076f |
write access media and therefore is suitable for housing of an
|
|
|
0e076f |
arbitrary file system, e.g. udf, vfat, ext2, etc. This,
|
|
|
0e076f |
and this alone, qualifies DVD+RW support for kernel
|
|
|
0e076f |
implementation. However, I have to recommend to
|
|
|
0e076f |
deploy it with caution, see tutorial
|
|
|
0e076f |
for further details. Also note that not all OEMs seem to live
|
|
|
0e076f |
up to the promise of true random write access. As for the
|
|
|
0e076f |
moment of this writing apparenly only 2nd generation
|
|
|
0e076f |
Ricoh-based units (see
|
|
|
0e076f |
HREF="http://www.dvdplusrw.org/">dvdplusrw.org for
|
|
|
0e076f |
generation listings) equipped with later firmware can sustain
|
|
|
0e076f |
I/O fragmentation (see Technical Ramblings below for further
|
|
|
0e076f |
details) and perform reliably.
|
|
|
0e076f |
|
|
|
0e076f |
|
|
|
0e076f |
|
|
|
0e076f |
|
|
|
0e076f |
Q. What are the dvd+rw-tools for?
|
|
|
0e076f |
|
|
|
0e076f |
A. As implied/already mentioned - to master the
|
|
|
0e076f |
HREF="Blu-ray/">Blu-ray Disc and DVD media, both +RW/+R and
|
|
|
0e076f |
-R[W]. I could simply refer to the
|
|
|
0e076f |
tutorial below, but figured that couple of words about the
|
|
|
0e076f |
[original] design ideas behind growisofs, the principal
|
|
|
0e076f |
burning utility, wouldn't harm. Even though a modified
|
|
|
0e076f |
kernel can let you put for example an ext2 file system on
|
|
|
0e076f |
DVD+RW, it's probably not very practical, because you most
|
|
|
0e076f |
likely want to access the data on an arbitrary computer.
|
|
|
0e076f |
Or in other words you most likely want ISO9660. The trouble is
|
|
|
0e076f |
that you might as well want to add data now and then.
|
|
|
0e076f |
And what options do you have in the lack of multiple sessions
|
|
|
0e076f |
(no, DVD+RW has no notion of multiple sessions)? Complete
|
|
|
0e076f |
re-mastering which takes more and more time as data set grows?
|
|
|
0e076f |
Well, yes, unless you employ growisofs! Growisofs
|
|
|
0e076f |
provides the way to both lay down and grow an ISO9660
|
|
|
0e076f |
file system on (as well as to burn an arbitrary pre-mastered
|
|
|
0e076f |
image to) all supported optical media.
|
|
|
0e076f |
|
|
|
0e076f |
|
|
|
0e076f |
|
|
|
0e076f |
|
|
|
0e076f |
Q. But if they support both + and - recording
|
|
|
0e076f |
strategies, why are they called dvd+rw-tools?
|
|
|
0e076f |
|
|
|
0e076f |
A. For historical/nostalgical reasons, as originally they did
|
|
|
0e076f |
support exclusively DVD+plus. On the other hand now, when the
|
|
|
0e076f |
vast majority of DVD burners that are being introduced to the
|
|
|
0e076f |
market today are DVD+capable, the name most likely refers to
|
|
|
0e076f |
your unit in either case. And you can always consider the plus
|
|
|
0e076f |
in the name as notion of a unique quality, such as
|
|
|
0e076f |
"seamless" multisessioning, not as reference to some
|
|
|
0e076f |
particular format:-)
|
|
|
0e076f |
|
|
|
0e076f |
|
|
|
0e076f |
|
|
|
0e076f |
|
|
|
0e076f |
Q. Do I still need
|
|
|
0e076f |
HREF="http://cdrecord.berlios.de/old/private/cdrecord.html">cdrtools?
|
|
|
0e076f |
|
|
|
0e076f |
|
|
|
0e076f |
A. Yes. It should be explicitly noted that growisofs is a
|
|
|
0e076f |
front-end to mkisofs, i.e. invokes mkisofs to perform the
|
|
|
0e076f |
actual ISO9660 file system layout. Secondly, the DVD burners
|
|
|
0e076f |
available on the market can burn even CD-R[W] media and
|
|
|
0e076f |
cdrecord is the tool for this job [and this job only].
|
|
|
0e076f |
|
|
|
0e076f |
|
|
|
0e076f |
|
|
|
0e076f |
|
|
|
0e076f |
|
|
|
0e076f |
Q. There are dual-format DVD+RW/-RW units
|
|
|
0e076f |
available on the market, e.g. SONY DRU500. Can I use
|
|
|
0e076f |
dvd+rw-tools with it/them?
|
|
|
0e076f |
|
|
|
0e076f |
|
|
|
0e076f |
A. If the question is if you can use dvd+rw-tools to master the
|
|
|
0e076f |
DVD+RW/+R media in a ±RW drive, then the answer always
|
|
|
0e076f |
was "definitely yes." If the question really is if
|
|
|
0e076f |
you can use dvd+rw-tools to burn even DVD-R[W] media,
|
|
|
0e076f |
then I have the pleasure to inform you that as of version 5.0
|
|
|
0e076f |
dvd+rw-tools provide experimental support even for
|
|
|
0e076f |
recording of DVD-R[W] media and refer you to a
|
|
|
0e076f |
dedicated page for further details.
|
|
|
0e076f |
|
|
|
0e076f |
-->
|
|
|
0e076f |
|
|
|
0e076f |
|
|
|
0e076f |
|
|
|
0e076f |
Q. Does it work with my recorder unit?
|
|
|
0e076f |
|
|
|
0e076f |
|
|
|
0e076f |
A. If your unit is
|
|
|
0e076f |
HREF="http://www.t10.org/drafts.htm#mmc3">MMC compliant,
|
|
|
0e076f |
then the answer is "most likely it
|
|
|
0e076f |
just does." Well, as the probability of your unit being
|
|
|
0e076f |
non-MMC compliant is virtually zero, the answer in practice is
|
|
|
0e076f |
unconditionally "most likely."
|
|
|
0e076f |
The [core] tools were reported to work with a wide range of
|
|
|
0e076f |
drives, including [but not limited to] <NOBR>HP
|
|
|
0e076f |
dvd[12345]x0i,</NOBR> <NOBR>Ricoh MP512x,</NOBR> <NOBR>Philips
|
|
|
0e076f |
DVDRW[248]xx,</NOBR> <NOBR>SONY DRU-[157]x0,</NOBR> <NOBR>NEC
|
|
|
0e076f |
ND-[1234]xx0,</NOBR> <NOBR>TDK indiDVD 4x0N,</NOBR>
|
|
|
0e076f |
<NOBR>Plextor PX-[57]xx,</NOBR> <NOBR>Benq DW[48]00A,</NOBR>
|
|
|
0e076f |
<NOBR>OptoRite DD0[24]0x,</NOBR> <NOBR>Lite-On
|
|
|
0e076f |
LDW-[4816]xxS,</NOBR> as well as nonplus
|
|
|
0e076f |
units such as <NOBR>Pioneer DVR-x0[45679],</NOBR> <NOBR>LG
|
|
|
0e076f |
GxA-40[248]x,</NOBR> <NOBR>Toshiba SD-R[56]112,</NOBR>
|
|
|
0e076f |
<NOBR>Panasonic UJ-811</NOBR>, <NOBR>LF-D[35]1x,</NOBR> and not
|
|
|
0e076f |
the least all-mighty
|
|
|
0e076f |
<NOBR>SW-5582...</NOBR>
|
|
|
0e076f |
|
|
|
0e076f |
|
|
|
0e076f |
|
|
|
0e076f |
|
|
|
0e076f |
Q. Is there a GUI front-end available for
|
|
|
0e076f |
dvd+rw-tools?
|
|
|
0e076f |
|
|
|
0e076f |
|
|
|
0e076f |
A. K3b, version 0.10
|
|
|
0e076f |
and later, and
|
|
|
0e076f |
HREF="http://ftp.gnome.org/pub/GNOME/sources/nautilus-cd-burner/">nautilus-cd-burner,
|
|
|
0e076f |
version 0.5.1 and later, are both hiding growisofs behind their
|
|
|
0e076f |
pretty buttons and menus:-) Keep in mind that those are not
|
|
|
0e076f |
directly related to <NOBR>dvd+rw-tools</NOBR> development
|
|
|
0e076f |
effort and GUI users should turn elsewhere for end-user
|
|
|
0e076f |
support. Oh! dvd+rw-tools 5.10.x is a minimum requirement for
|
|
|
0e076f |
GUI frontends...
|
|
|
0e076f |
|
|
|
0e076f |
|
|
|
0e076f |
|
|
|
0e076f |
|
|
|
0e076f |
Q. I don't run Linux. What are my options?
|
|
|
0e076f |
|
|
|
0e076f |
|
|
|
0e076f |
A. Version 5.4 adds support for
|
|
|
0e076f |
HREF="http://www.mosha.net/05-dvdrw/dvdrw.shtml">OpenBSD/NetBSD.
|
|
|
0e076f |
Version 5.6 adds support for Solaris 2.x
|
|
|
0e076f |
SIZE=-1>[commercial licensing
|
|
|
0e076f |
terms for distribution on Solaris are to be settled with
|
|
|
0e076f |
HREF="http://www.inserve.se/">Inserve Technology]</FONT>.
|
|
|
0e076f |
Version 5.8 features
|
|
|
0e076f |
HREF="http://www.freebsd.org/doc/en_US.ISO8859-1/books/handbook/creating-dvds.html">FreeBSD
|
|
|
0e076f |
port contributed by Matthew Dillon, FreeBSD Development Team
|
|
|
0e076f |
alumnus. <NOBR>Hewlett-Packard</NOBR> Company has donated
|
|
|
0e076f |
<NOBR>HP-UX 11</NOBR> support for
|
|
|
0e076f |
5.14<SUP>(*)</SUP>. IRIX 6.x support appears in
|
|
|
0e076f |
5.19, Win32 one - in 6.0,
|
|
|
0e076f |
while <NOBR>Mac OS X</NOBR> - in 7.0...
|
|
|
0e076f |
|
|
|
0e076f |
|
|
|
0e076f |
|
|
|
0e076f |
¡
|
|
|
0e076f |
Common usage tip!<SUP> </SUP>Whenever
|
|
|
0e076f |
separately available [and unless stated otherwise], do use
|
|
|
0e076f |
character-type device entry with <NOBR>dvd+rw-tools,</NOBR>
|
|
|
0e076f |
e.g. OpenBSD/NetBSD users should stick to <TT>/dev/
|
|
|
0e076f |
COLOR="red">r</FONT>cdXc</TT>.
|
|
|
0e076f |
|
|
|
0e076f |
|
|
|
0e076f |
<FONT SIZE="-1">FreeBSD tip! If you have an IDE unit,
|
|
|
0e076f |
HREF="http://www.cuivre.fr.eu.org/~thomas/atapicam/">atapicam
|
|
|
0e076f |
is your mantra! Secondly, if you have <TT>devfs</TT> mounted,
|
|
|
0e076f |
you might have to mount
|
|
|
0e076f |
<TT>fdescfs</TT> as well.</FONT> -->
|
|
|
0e076f |
|
|
|
0e076f |
<FONT SIZE="-1"><SUP>(*)</SUP></FONT>
|
|
|
0e076f |
<FONT SIZE="-1">As of 5.14 HP-UX support was classified as
|
|
|
0e076f |
"initial." Version 5.18 in turn is the one which has
|
|
|
0e076f |
undergone HP quality assurance testing
|
|
|
0e076f |
and is delivered on HP
|
|
|
0e076f |
software depot.</FONT>
|
|
|
0e076f |
|
|
|
0e076f |
|
|
|
0e076f |
|
|
|
0e076f |
|
|
|
0e076f |
|
|
|
0e076f |
|
|
|
0e076f |
Foreword
|
|
|
0e076f |
|
|
|
0e076f |
As of May 2003 I've decided to advise users to
|
|
|
0e076f |
turn to <
|
|
|
0e076f |
HREF="mailto:cdwrite@other.debian.org">cdwrite@other.debian.org>
|
|
|
0e076f |
on support matters. It's an open list, meaning that you don't have
|
|
|
0e076f |
to be subscribed to post
|
|
|
0e076f |
a problem report. List archives can be found at both
|
|
|
0e076f |
HREF="http://lists.debian.org/cdwrite/">subscribe page and
|
|
|
0e076f |
HREF="http://www.mail-archive.com/cdwrite%40other.debian.org/">mail-archive.com.
|
|
|
0e076f |
When submitting report, provide versioning information, exact
|
|
|
0e076f |
command line, exact output generated by the program and
|
|
|
0e076f |
complement it with <NOBR>dvd+rw-mediainfo</NOBR> output for
|
|
|
0e076f |
resulting recording. Do check couple of last
|
|
|
0e076f |
HREF="http://lists.debian.org/cdwrite/">archived months, as the
|
|
|
0e076f |
issue might have been discussed recently. If you've chosen to
|
|
|
0e076f |
contact me personally and haven't heard back within a week or so, then
|
|
|
0e076f |
you most likely overlooked something on this page. Please read it more
|
|
|
0e076f |
attentively...
|
|
|
0e076f |
|
|
|
0e076f |
Special thanks for hardware donations [in
|
|
|
0e076f |
chronological order]:
|
|
|
0e076f |
|
|
|
0e076f |
|
|
|
0e076f |
ALT="Inserve Technology" BORDER=0>
|
|
|
0e076f |
|
|
|
0e076f |
|
|
|
0e076f |
ALT="HP" BORDER=0>
|
|
|
0e076f |
|
|
|
0e076f |
|
|
|
0e076f |
ALT="LinuxFund" BORDER=0>
|
|
|
0e076f |
|
|
|
0e076f |
|
|
|
0e076f |
SRC="commtech.gif" ALT="comm*tech" BORDER=0>
|
|
|
0e076f |
|
|
|
0e076f |
|
|
|
0e076f |
|
|
|
0e076f |
Tutorial
|
|
|
0e076f |
|
|
|
0e076f |
|
|
|
0e076f |
|
|
|
0e076f |
|
|
|
0e076f |
|
|
|
0e076f |
If your burner unit is managed by some
|
|
|
0e076f |
<NOBR>Linux<SUP>(*)</SUP></NOBR> removable media
|
|
|
0e076f |
automounting/autoplaying facility, such as autofs, supermount,
|
|
|
0e076f |
subfs/submount, magicdev, autorun or similar, take it out of its
|
|
|
0e076f |
control! I can't help you with the latter, check your system
|
|
|
0e076f |
documentation (such as google perhaps:-) for specific instructions.
|
|
|
0e076f |
<FONT COLOR="brown">Failure to take your unit out of
|
|
|
0e076f |
<NOBR>Linux<SUP>(*)</SUP></NOBR> automounting/autoplaying facility
|
|
|
0e076f |
control can result in busted recording, a coaster!</FONT> At the
|
|
|
0e076f |
very least you have to make sure your unit is not automounted during
|
|
|
0e076f |
recordings.
|
|
|
0e076f |
exclusive use," but it doesn't. Therefore the trouble... --->
|
|
|
0e076f |
|
|
|
0e076f |
|
|
|
0e076f |
|
|
|
0e076f |
<FONT SIZE="-1"><SUP>(*)</SUP></FONT>
|
|
|
0e076f |
<FONT SIZE="-1">dvd+rw-tools support Solaris volume manager and
|
|
|
0e076f |
IRIX mediad in more gracious manner and it's safe to leave recorder
|
|
|
0e076f |
under their control.</FONT>
|
|
|
0e076f |
|
|
|
0e076f |
|
|
|
0e076f |
Remember to consult
|
|
|
0e076f |
HREF="hcn.html">Hardware Compatibility Notes for possible
|
|
|
0e076f |
caveats or vendor-specific instructions for your unit. Well, such
|
|
|
0e076f |
reminder belongs at the end of tutorial, but I consider it important
|
|
|
0e076f |
enough to bring it up already here:-)
|
|
|
0e076f |
|
|
|
0e076f |
If you have an IDE unit and run 2.4.x
|
|
|
0e076f |
kernel, you most likely want to "route" it through ide-scsi
|
|
|
0e076f |
emulation layer by either:
|
|
|
0e076f |
|
|
|
0e076f |
|
|
|
0e076f |
passing "<TT>hd<FONT COLOR="red">X</FONT>=ide-scsi</TT>"
|
|
|
0e076f |
argument to kernel;
|
|
|
0e076f |
appending following lines to your /etc/modules.conf:
|
|
|
0e076f |
|
|
|
0e076f |
options ide-cd ignore=hd<FONT COLOR="red">X</FONT>
|
|
|
0e076f |
pre-install sg modprobe ide-scsi
|
|
|
0e076f |
pre-install sr_mod modprobe ide-scsi
|
|
|
0e076f |
pre-install ide-scsi modprobe ide-cd
|
|
|
0e076f |
|
|
|
0e076f |
|
|
|
0e076f |
|
|
|
0e076f |
Keep in mind that once hd<FONT COLOR="red">X</FONT>
|
|
|
0e076f |
is routed through ide-scsi, you can no longer refer to <TT>/dev/hd
|
|
|
0e076f |
COLOR="red">X</FONT></TT><SUP>(*)</SUP>, but to corresponding
|
|
|
0e076f |
<TT>/dev/scd<FONT COLOR="red">N</FONT></TT> only.
|
|
|
0e076f |
|
|
|
0e076f |
|
|
|
0e076f |
|
|
|
0e076f |
<FONT SIZE="-1"><SUP>(*)</SUP></FONT>
|
|
|
0e076f |
<FONT SIZE="-1">well, except as in <TT>hdparm -d [0|1] /dev/hd
|
|
|
0e076f |
COLOR="red">X</FONT></TT>. As for DMA settings. Several users of
|
|
|
0e076f |
NEC[-based] units have reported that their systems crash during DVD
|
|
|
0e076f |
recording. The problem appears to be related to DMA settings, at least
|
|
|
0e076f |
switching it off reportedly helps. The problem appears to be specific to
|
|
|
0e076f |
some IDE chipsets...</FONT>
|
|
|
0e076f |
|
|
|
0e076f |
|
|
|
0e076f |
|
|
|
0e076f |
If you have an external unit, just get
|
|
|
0e076f |
it working as CD-ROM first. I myself have no personal experience
|
|
|
0e076f |
whatsoever with USB or
|
|
|
0e076f |
HREF="http://www.linux1394.org/">IEEE1394/Firewire optical storage
|
|
|
0e076f |
devices and have to direct you elsewhere for specific instructions. I
|
|
|
0e076f |
however am confident that if you manage to get your drive working
|
|
|
0e076f |
reliably as <NOBR>CD-ROM</NOBR> and <NOBR>CD-R[W]</NOBR>
|
|
|
0e076f |
burner, then you won't have any troubles with dvd+rw-tools either. USB
|
|
|
0e076f |
connected drives were reported to be working fine since eternity.
|
|
|
0e076f |
Firewire connected drives in turn were reported to fail miserably under
|
|
|
0e076f |
2.4.18. The failure didn't seem to be DVD recording related as it
|
|
|
0e076f |
reportedly failed burning even CD-R media. Firewire support was
|
|
|
0e076f |
substantially revamped in 2.4.19, and dvd+rw-tools were reported to
|
|
|
0e076f |
work with this and later kernels.
|
|
|
0e076f |
|
|
|
0e076f |
If you're running 2.4.19 or .20, consider
|
|
|
0e076f |
applying this drivers/scsi/sg.c patch.
|
|
|
0e076f |
The bug is fixed in .21. I write "consider" and not
|
|
|
0e076f |
"do" for the following reasons:
|
|
|
0e076f |
|
|
|
0e076f |
|
|
|
0e076f |
dvd+rw-tools are not affected by this bug (as they don't use SG_IO
|
|
|
0e076f |
interface), cdrecord [potentially] is;
|
|
|
0e076f |
I however haven't actually experienced the problem with cdrecord
|
|
|
0e076f |
(maybe yet, kernel could have managed to keep buffers neatly aligned
|
|
|
0e076f |
while talking to cdrecord those times I tried), it was VMware that has
|
|
|
0e076f |
failed miserably on me;
|
|
|
0e076f |
|
|
|
0e076f |
|
|
|
0e076f |
As of version 5.6 dvd+rw-tools add support for SG_IO
|
|
|
0e076f |
pass-through or in other words support for Linux 2>=5[.43],
|
|
|
0e076f |
where "generic" SCSI interface can be bypassed by issuing
|
|
|
0e076f |
SG_IO ioctl directly against block device, such as <TT>/dev/hd
|
|
|
0e076f |
COLOR="red">X</FONT></TT>. I wish it worked without need for
|
|
|
0e076f |
HREF="http://marc.theaimsgroup.com/?t=105410790500005&r=1&w=2">interim
|
|
|
0e076f |
patches #1 and
|
|
|
0e076f |
HREF="ide-cd-2.5.69.+patch">#2, (the latter is relative to
|
|
|
0e076f |
2.5.69-75, the 1st problem is addressed in .71, 2nd one - .75-bk3 in
|
|
|
0e076f |
"
|
|
|
0e076f |
HREF="http://marc.theaimsgroup.com/?l=linux-kernel&m=105787192005635&w=2">last
|
|
|
0e076f |
minute" prior first 2.6 cut. As for 2.6 in more general sense.
|
|
|
0e076f |
As you can imagine this new interface renders ide-scsi layer
|
|
|
0e076f |
superfluous and "the[ir] official plan™" is to scrap
|
|
|
0e076f |
it. I'm not really fond of the idea, but not for /dev/sg* account. I
|
|
|
0e076f |
mean I [personally] would prefer to keep ide-scsi and use SG_IO
|
|
|
0e076f |
pass-through with <TT>/dev/scdN</TT>, rather than with
|
|
|
0e076f |
<TT>/dev/hdX</TT>:-)
|
|
|
0e076f |
|
|
|
0e076f |
If you have to make dvd+rw-tools work under Linux
|
|
|
0e076f |
kernel 2.6.8, then upgrade the tool-chain to 5.21.x or later and
|
|
|
0e076f |
manually reward the installed binaries with set-root-uid flag. But the
|
|
|
0e076f |
"supported" recommendation is to just stay away from this
|
|
|
0e076f |
particular kernel version. As for 2.6>8, dvd+rw-tools 5.21.x is
|
|
|
0e076f |
requirement. Oh! dvd+rw-booktype utility would require set-root-uid
|
|
|
0e076f |
privilege then. Given its semi-official status and the fact that this
|
|
|
0e076f |
utility works only with limited number of units, installation procedure
|
|
|
0e076f |
abstains from installing dvd+rw-booktype set-root-uid, leaving
|
|
|
0e076f |
this security sensitive choice to the end-user.
|
|
|
0e076f |
|
|
|
0e076f |
Download, unpack and compile the
|
|
|
0e076f |
HREF="tools/?M=D">the tool-chain. To build the thing do pick the
|
|
|
0e076f |
.tar.gz archive, which contains Makefile as well as .spec file. You
|
|
|
0e076f |
will need both C and C++ compilers installed. Separate
|
|
|
0e076f |
source code files found in the download catalog
|
|
|
0e076f |
are provided mainly for on-line reference purposes (such as
|
|
|
0e076f |
HREF="tools/growisofs.c">revision history:-).
|
|
|
0e076f |
|
|
|
0e076f |
If your Linux kernel supports multiple ABIs (e.g.
|
|
|
0e076f |
Linux-sparc64 can run even 32-bit Linux-sparc applications, as well as
|
|
|
0e076f |
Linux-x86_64 can execute legacy 32-bit i386 binaries), make sure you
|
|
|
0e076f |
compile for native 64-bit ABI (which can normally be done with
|
|
|
0e076f |
'<TT>make TARGET_ARCH=-m64</TT>'). The problem here is that 64-bit
|
|
|
0e076f |
kernel has to explicitly convert ioctl structures passed by 32-bit
|
|
|
0e076f |
applications and apparently it does really lousy job when it comes to
|
|
|
0e076f |
CDROM_SEND_PACKET ioctl deployed by dvd+rw-tools.
|
|
|
0e076f |
|
|
|
0e076f |
As new media products and brands are being
|
|
|
0e076f |
introduced to the market all the time, it apparently pays off to
|
|
|
0e076f |
periodically check for firmware updates. For elder units
|
|
|
0e076f |
firmware update might even be an absolute requirement for using
|
|
|
0e076f |
new media. Special note for HP users. HP no longer posts firmware
|
|
|
0e076f |
updates on a web-page. Instead they let some Windows auto-update gizmo
|
|
|
0e076f |
to pick firmware updates among <NOBR><TT>dvd[1-6]00*.exe</TT></NOBR>
|
|
|
0e076f |
files in
|
|
|
0e076f |
HREF="ftp://ftp.hp.com/pub/information_storage/software/">their FTP
|
|
|
0e076f |
directory, so that readers of this page tend to miss them...
|
|
|
0e076f |
|
|
|
0e076f |
Formatting the BD and DVD+RW media.
|
|
|
0e076f |
Virgin BD and DVD+RW media needs to be initally formatted prior usage.
|
|
|
0e076f |
Once again, only virgin BD and DVD+RW media needs to be
|
|
|
0e076f |
formatted. As of version 5.10 growisofs detects blanks and applies
|
|
|
0e076f |
initial formatting procedure automatically. Otherwise same effect can
|
|
|
0e076f |
be achieved by passing the device name, e.g. <TT>/dev/scd0</TT>, as an
|
|
|
0e076f |
argument to dvd+rw-format. Well,
|
|
|
0e076f |
in BD case it does offer more flexibility than
|
|
|
0e076f |
growisofs. To make formatting process reasonably fast, less than 1
|
|
|
0e076f |
minute, the media gets formatted only partially, as you can notice by
|
|
|
0e076f |
observing progress indicator displayed by dvd+rw-format. The final
|
|
|
0e076f |
indicator value varies from firmware to firmware, values as low as 1.6%
|
|
|
0e076f |
were observed. But it does not mean that you can only write that
|
|
|
0e076f |
little. The unit keeps formatting transparently, as you add more
|
|
|
0e076f |
data. Oh! Do keep in mind that DVD capacity of 4.7GB is expressed in
|
|
|
0e076f |
salesman's GB, i.e. 1000<SUP>3</SUP> and not 1024<SUP>3</SUP>. And
|
|
|
0e076f |
so is one of BD.
|
|
|
0e076f |
|
|
|
0e076f |
It was observed that excessive reformats can render
|
|
|
0e076f |
DVD+RW media unusable already after 10-20 reformats. It appears to be a
|
|
|
0e076f |
firmware deficiency, not some common media defect [at least it was
|
|
|
0e076f |
perfectly possible to salvage the media in a unit of different brand],
|
|
|
0e076f |
but I don't recommend [enforced] reformat in either case.
|
|
|
0e076f |
|
|
|
0e076f |
Note that re-formatting procedure does not
|
|
|
0e076f |
substitute for blanking. If you want to nullify the media, e.g. for
|
|
|
0e076f |
privacy reasons, do it explicitly with '<TT>growisofs <NOBR>-Z</NOBR>
|
|
|
0e076f |
/dev/scd<FONT COLOR="red">N</FONT>=/dev/zero</TT>'. Otherwise just
|
|
|
0e076f |
write over previous recording as it simply wasn't there, no
|
|
|
0e076f |
re-formatting is required.
|
|
|
0e076f |
|
|
|
0e076f |
|
|
|
0e076f |
DVD+R media does not require any formatting
|
|
|
0e076f |
procedure applied and is ready to use out-of-the-box. Apparently, a
|
|
|
0e076f |
reminder that 1st generation units (Ricoh MP5120A and derivatives)
|
|
|
0e076f |
are not capable of burning DVD+R is needed.--->
|
|
|
0e076f |
|
|
|
0e076f |
Burning with
|
|
|
0e076f |
HREF="tools/growisofs.c">growisofs. There is hardly a need for
|
|
|
0e076f |
manual for growisofs. In a nutshell growisofs just passes all command
|
|
|
0e076f |
line arguments to mkisofs and dumps its output directly onto the media.
|
|
|
0e076f |
The first part means that you basically can [well, should]
|
|
|
0e076f |
consult mkisofs manual page and
|
|
|
0e076f |
accompanying reference documentation (including multisession related
|
|
|
0e076f |
section[s]) and the second part means that you shouldn't expect an
|
|
|
0e076f |
ISO-image on the standard output (nor make sure you have enough free
|
|
|
0e076f |
temporary storage<TT>:-)</TT>. Differences from mkisofs command line
|
|
|
0e076f |
are:
|
|
|
0e076f |
|
|
|
0e076f |
|
|
|
0e076f |
you may not use -o option;
|
|
|
0e076f |
you don't have to specify -C option, growisofs will construct one
|
|
|
0e076f |
for you;
|
|
|
0e076f |
there is internal -Z option for initial session recording, this
|
|
|
0e076f |
substitutes for originally suggested 'mkisofs | dd of=/dev/scd0';
|
|
|
0e076f |
|
|
|
0e076f |
|
|
|
0e076f |
Otherwise everything that applies to
|
|
|
0e076f |
[multisession] mastering with mkisofs applies to growisofs as well. For
|
|
|
0e076f |
example just like with mkisofs you should make a note on which options
|
|
|
0e076f |
you used to master the initial "session" with and stick to
|
|
|
0e076f |
them, e.g.:
|
|
|
0e076f |
|
|
|
0e076f |
|
|
|
0e076f |
growisofs -Z /dev/scd0 <FONT COLOR="red">-R -J</FONT> /some/files
|
|
|
0e076f |
growisofs -M /dev/scd0 <FONT COLOR="red">-R -J</FONT> /more/files
|
|
|
0e076f |
|
|
|
0e076f |
|
|
|
0e076f |
Oh! Do make sure you have at least mkisofs
|
|
|
0e076f |
COLOR="red">1.14</FONT> on your $PATH (mkisofs 1.14 is part of cdrtools
|
|
|
0e076f |
1.10). If you consider passing <TT>/same/files</TT> as argument, or in
|
|
|
0e076f |
other words consider deploying growisofs for incremental
|
|
|
0e076f |
multisession backups, then you shall find
|
|
|
0e076f |
HREF="mkisofs-2.01a16-root.diff">this '-old-root' extension to
|
|
|
0e076f |
mkisofs <FONT COLOR="red">2
|
|
|
0e076f |
HREF="mkisofs-2.0-root.diff">.0-2.01</FONT> simply indispensable.
|
|
|
0e076f |
The idea and implementation by
|
|
|
0e076f |
HREF="http://home.pages.de/~ohly/#mkisofs-root">Patrick Ohly is to
|
|
|
0e076f |
"graft" recording sessions as separate directories. Each
|
|
|
0e076f |
backup increment/directory is ment to contain both updated files and
|
|
|
0e076f |
references to previously backed up ones, which facilitates
|
|
|
0e076f |
comparison between increments as well as fine-graded restore.
|
|
|
0e076f |
|
|
|
0e076f |
Number of users asked about opposite to
|
|
|
0e076f |
multisessioning: multivolume support. Being essentially a recording
|
|
|
0e076f |
program growisofs does not support multiple volumes by itself. There're
|
|
|
0e076f |
couple of front-ends I can recommend that arrange for this:
|
|
|
0e076f |
HREF="http://scdbackup.sourceforge.net/main_eng.html">scdbackup and
|
|
|
0e076f |
shunt. But back to
|
|
|
0e076f |
growisofs...
|
|
|
0e076f |
|
|
|
0e076f |
In addition to intuitive -Z interpretation,
|
|
|
0e076f |
growisofs [version 3.3 and later] recognizes special form of -Z command
|
|
|
0e076f |
line option which permits burning of arbitrary pre-mastered images. The
|
|
|
0e076f |
"magic" command is:
|
|
|
0e076f |
|
|
|
0e076f |
|
|
|
0e076f |
growisofs -Z /dev/scd0<FONT COLOR="red">=</FONT>image.iso
|
|
|
0e076f |
|
|
|
0e076f |
|
|
|
0e076f |
where <TT>image.iso</TT> represents an arbitrary
|
|
|
0e076f |
object in the file system, such as file, named pipe or device
|
|
|
0e076f |
entry. No, nothing is "growing" here and command name is
|
|
|
0e076f |
counter-intuitive in this particular context. And here is even less
|
|
|
0e076f |
intuitive<TT>:-)</TT> If you wish to burn down output generated by an
|
|
|
0e076f |
arbitrary program, you can use:
|
|
|
0e076f |
|
|
|
0e076f |
|
|
|
0e076f |
dumpsomething | growisofs -Z /dev/scd0=<FONT COLOR="red">/dev/fd/0</FONT>
|
|
|
0e076f |
|
|
|
0e076f |
|
|
|
0e076f |
Burning BD-R/DVD±R implies extra limitations:
|
|
|
0e076f |
|
|
|
0e076f |
|
|
|
0e076f |
|
|
|
0e076f |
Needless to say that you have only one shot with -Z
|
|
|
0e076f |
option<TT>:-)</TT>
|
|
|
0e076f |
|
|
|
0e076f |
|
|
|
0e076f |
Apparently media needs to be manually reloaded [ejected and pushed
|
|
|
0e076f |
back again] after every burning session (well, if you haven't patched
|
|
|
0e076f |
the kernel that is<TT>:-)</TT>
|
|
|
0e076f |
--->
|
|
|
0e076f |
|
|
|
0e076f |
Unlike DVD+RW, DVD±R media does have notion of multiple
|
|
|
0e076f |
sessions. However! Not all legacy units can "see"
|
|
|
0e076f |
beyond the first one. Few DVD-ROM units are capable of DVD-R
|
|
|
0e076f |
multiborder playback, even fewer support DVD+R multisessioning. In
|
|
|
0e076f |
other words your DVD burner might be the only unit in your vicinity
|
|
|
0e076f |
capable to access data added at different occasions.
|
|
|
0e076f |
|
|
|
0e076f |
Even if your DVD unit does "sense" multiple sessions,
|
|
|
0e076f |
Linux kernel [2.4] sometimes fails to pull that information from the
|
|
|
0e076f |
drive<TT>:-(</TT> Till the problem is looked into and resolved you can
|
|
|
0e076f |
work it around by reloading corresponding driver, most likely
|
|
|
0e076f |
'<TT>rmmod sr_mod</TT>'.
|
|
|
0e076f |
|
|
|
0e076f |
Linux kernel 2.6<
|
|
|
0e076f |
HREF="http://marc.theaimsgroup.com/?l=linux-kernel&m=110330852622064&w=2">10
|
|
|
0e076f |
users might experience
|
|
|
0e076f |
HREF="http://marc.theaimsgroup.com/?l=linux-kernel&m=108827602322464&w=2">problems
|
|
|
0e076f |
mounting multisession media with last session starting beyond
|
|
|
0e076f |
2.2GB boundary. As fast-acting remedy I can suggest to route your unit
|
|
|
0e076f |
through ide-scsi, the way it was under 2.4. Even though it's declared
|
|
|
0e076f |
unsupported it actually still works in 2.6 (I for one still use it).
|
|
|
0e076f |
|
|
|
0e076f |
If you go for BD-R/DVD±R multisessioning, you have to use
|
|
|
0e076f |
mkisofs from cdrtools-2.0
|
|
|
0e076f |
or later or apply this patch.
|
|
|
0e076f |
|
|
|
0e076f |
And when it comes to DVD+R Double Layer and <NOBR>DVD-R</NOBR>
|
|
|
0e076f |
Dual Layer recordings, growisofs applies yet another limitation,
|
|
|
0e076f |
purely artificial. Taking into consideration Double Layer media prices
|
|
|
0e076f |
growisofs is programmed to refuse to perform unappendable
|
|
|
0e076f |
recordings which are less than 1/2 of blank capacity and to advice
|
|
|
0e076f |
to use single layer media instead.
|
|
|
0e076f |
|
|
|
0e076f |
DVD-R Dual Layer multisessioning is not supported for a reason
|
|
|
0e076f |
discussed on the -RW companion page. Once
|
|
|
0e076f |
again, as of the moment of this writing <NOBR>DVD-R</NOBR> Dual Layer
|
|
|
0e076f |
recordings come out unappendable and can not be grown.
|
|
|
0e076f |
|
|
|
0e076f |
|
|
|
0e076f |
|
|
|
0e076f |
And once again, do keep in mind that 4.7GB are
|
|
|
0e076f |
salesman's GB, i.e. 1000<SUP>3</SUP> and not 1024<SUP>3</SUP>. If
|
|
|
0e076f |
translated to "real" GB, single layer
|
|
|
0e076f |
<NOBR>DVD±R[W]</NOBR> capacity is not larger than 4.4GiB, and BD
|
|
|
0e076f |
- not larger than 23.3GiB! It should also be noted that earlier
|
|
|
0e076f |
growisofs versions did not check if there is enough space on media to
|
|
|
0e076f |
accommodate the data set to be burned, meaning that it was your sole
|
|
|
0e076f |
responsibility to make sure "overburn" condition is not
|
|
|
0e076f |
raised. As of version 5.2 growisofs performs the necessary checks
|
|
|
0e076f |
for you and refuses to start recording if "overburn"
|
|
|
0e076f |
condition appears to be unavoidable. This behaviour can be overridden
|
|
|
0e076f |
with <TT>-overburn</TT> command-line option.
|
|
|
0e076f |
|
|
|
0e076f |
If you're satisfied with growisofs, then you
|
|
|
0e076f |
should just proceed to the next chapter
|
|
|
0e076f |
and abstain from applying the optional 2.4.x kernel patch. If
|
|
|
0e076f |
you haven't stopped reading beyond this line,
|
|
|
0e076f |
HREF="linux-2.4.patch">download the patch, apply it, rebuild the
|
|
|
0e076f |
kernel or modules and re-install (kernel or cdrom.o and sr_mod.o
|
|
|
0e076f |
modules, whichever appropriate), but don't ask me
|
|
|
0e076f |
HREF="http://www.linuxhq.com/patch-howto.html">how. As you could
|
|
|
0e076f |
have noticed, patch targets SCSI CD-ROM module. This means that you
|
|
|
0e076f |
have to "route" your IDE unit through ide-scsi to get this one
|
|
|
0e076f |
working. To see it in action, insert formatted DVD+RW media and try to
|
|
|
0e076f |
access it, '<TT>dd if=/dev/scd<FONT COLOR="red">N</FONT> count=0</TT>'
|
|
|
0e076f |
would do. Then verify that kernel logs "<TT>sr
|
|
|
0e076f |
COLOR="red">N</FONT>: mmc-3 profile: 1Ah</TT>". You should now be
|
|
|
0e076f |
able to '<TT>mkisofs -pad . | dd of=/dev/scd<FONT COLOR="red">N</FONT>
|
|
|
0e076f |
obs=32k</TT>' or even '<TT>mke2fs -b 2048 /dev/scd
|
|
|
0e076f |
COLOR="red">N</FONT></TT>' and observe kernel logging "<TT>sr
|
|
|
0e076f |
COLOR="red">N</FONT>: dirty DVD+RW media</TT>."
|
|
|
0e076f |
|
|
|
0e076f |
|
|
|
0e076f |
have to back it out first. The simplest way is probably to restore
|
|
|
0e076f |
<TT>drivers/scsi/sr*.[ch]</TT> and <TT>drivers/cdrom/cdrom.c</TT> from
|
|
|
0e076f |
your original Linux source code ditribution.-->
|
|
|
0e076f |
|
|
|
0e076f |
Linux 2.6 DVD+RW kernel support is planned in
|
|
|
0e076f |
line with DVD+MRW kernel support. This [unfortunately] means that
|
|
|
0e076f |
industry has to deliver a DVD+MRW capable unit first. Yes, the last
|
|
|
0e076f |
sentence means that despite all the promises, there are no such units
|
|
|
0e076f |
available on the market yet. As of the 1st of August 2003, Ricoh MP5240A,
|
|
|
0e076f |
Philips DVDRW416K or BenQ DW400A do not actually implement
|
|
|
0e076f |
Mt.Rainier/EasyWrite support. It remains to be seen if they will offer
|
|
|
0e076f |
it in form of firmware upgrade. In either case, the [original] project
|
|
|
0e076f |
goal is not only read-write support for DVD+[M]RW capable units
|
|
|
0e076f |
themselves, but even playback of DVD+MRW formatted media in legacy
|
|
|
0e076f |
DVD-ROM units (when defect list will be read and interpreted by OS
|
|
|
0e076f |
software in opposite to Mt.Rainier firmware).
|
|
|
0e076f |
|
|
|
0e076f |
Even though kernel now
|
|
|
0e076f |
permits to build and mount arbitrary file system, there is one thing you
|
|
|
0e076f |
must keep in mind before you just proceed, no matter how
|
|
|
0e076f |
tempting it might appear.
|
|
|
0e076f |
|
|
|
0e076f |
As you might know DVD+RW media can sustain only
|
|
|
0e076f |
around 1000 overwrites. The thing about fully fledged file systems
|
|
|
0e076f |
is that every read [or tight bunch of 'em] is accompanied by
|
|
|
0e076f |
corresponding i-node update or in other words a write! Now, let's say
|
|
|
0e076f |
you lookup the mount point (e.g. ls /mnt/dvd) ten times a day. This
|
|
|
0e076f |
gives you a 100 days lifetime on your mountpoint and therefore media.
|
|
|
0e076f |
Not really much, huh? So do use <TT>noatime</TT> mount option with
|
|
|
0e076f |
DVD+RW media or have it mounted read-only most of the time. However!
|
|
|
0e076f |
Every read-write mount "costs" a super-block update. So that
|
|
|
0e076f |
if you remount the media say 3 times a day, it would last for about a
|
|
|
0e076f |
year [
|
|
|
0e076f |
HREF="http://people.mandrakesoft.com/~quintela/supermount/">supermount
|
|
|
0e076f |
would exhaust the "budget" way sooner]... Defect management
|
|
|
0e076f |
[in firmware, a.k.a.
|
|
|
0e076f |
HREF="http://www.licensing.philips.com/information/mtr/">Mt.Rainier,
|
|
|
0e076f |
or at file system level] would improve the situation, but ideally
|
|
|
0e076f |
file system driver should definitely refrain from modifying the
|
|
|
0e076f |
super-block [marking it dirty] if nothing was actually written since
|
|
|
0e076f |
last mount. Given the development status of
|
|
|
0e076f |
HREF="http://sourceforge.net/projects/linux-udf/">Linux UDF the
|
|
|
0e076f |
chances for seeing the latter implemented [for UDF] are more than just
|
|
|
0e076f |
conceivable. The request is already filed and even possible solution is
|
|
|
0e076f |
being discussed. But why not give UDF a shot already then? By default
|
|
|
0e076f |
UDF write support is unfortunately disabled and you might have to
|
|
|
0e076f |
reconfigure the kernel and rebuild modules. Alternatively [my preferred
|
|
|
0e076f |
option actually] fetch the code at
|
|
|
0e076f |
HREF="http://sourceforge.net/projects/linux-udf/">SourceForge and
|
|
|
0e076f |
build the module separately. Of course you will have to fetch and build
|
|
|
0e076f |
udftools as well. But once it's done just type:
|
|
|
0e076f |
|
|
|
0e076f |
|
|
|
0e076f |
mkudffs --spartable=2 --media-type=cdrw /dev/scd<FONT COLOR="red">N</FONT>
|
|
|
0e076f |
mount -o rw,noatime /dev/scd<FONT COLOR="red">N</FONT> /mnt/cdrom
|
|
|
0e076f |
|
|
|
0e076f |
|
|
|
0e076f |
<TT>mkudffs</TT> command line options were suggested
|
|
|
0e076f |
by UDF maintainer, Ben Fennema.
|
|
|
0e076f |
|
|
|
0e076f |
Performance optimization. This paragraph
|
|
|
0e076f |
applies only if you've patched the kernel. As some of you might
|
|
|
0e076f |
remember the original recommendation was "do use <TT>obs=32k</TT>
|
|
|
0e076f |
for optimal performance." Well, it was rather naive of me to say
|
|
|
0e076f |
so, as common block device layer completely reorganizes the
|
|
|
0e076f |
stream so that '<TT>>/dev/scd0</TT>' is as good as '<TT>|dd
|
|
|
0e076f |
of=/dev/scd0 obs=32k</TT>'. It should also be noted that dumping to
|
|
|
0e076f |
/dev/scd0 puts quite a pressure on VM subsystem, as the data passes
|
|
|
0e076f |
through block buffer cache. To minimize the pressure and improve
|
|
|
0e076f |
overall system performance bind the cdrom device to a raw device, e.g.
|
|
|
0e076f |
'<TT>raw /dev/raw/raw1 /dev/scd0</TT>', growisofs will locate and use
|
|
|
0e076f |
it automatically. obs=32k makes perfect sense with /dev/raw devices,
|
|
|
0e076f |
but dd (as well as most other programs, e.g. tar) won't work as
|
|
|
0e076f |
/dev/raw expects specifically aligned buffer... As temporary
|
|
|
0e076f |
workaround, just to get you going so that you can start figuring things
|
|
|
0e076f |
out, consider
|
|
|
0e076f |
HREF="http://fy.chalmers.se/~appro/LD_*-gallery/index.html?aligned_io#aligned_io">this
|
|
|
0e076f |
"hacklet"...
|
|
|
0e076f |
|
|
|
0e076f |
|
|
|
0e076f |
|
|
|
0e076f |
|
|
|
0e076f |
|
|
|
0e076f |
Compatibility: caveat lector
|
|
|
0e076f |
|
|
|
0e076f |
|
|
|
0e076f |
|
|
|
0e076f |
This paragraph discusses "DVD-ROM
|
|
|
0e076f |
compatibility," or playability of already recorded media in legacy
|
|
|
0e076f |
units. Blank media compatibility issues, or cases such as failure to
|
|
|
0e076f |
start or fulfill recording because of poor media support by burner
|
|
|
0e076f |
firmware, are beyond the current scope. Turn to your vendor for list of
|
|
|
0e076f |
supported media and/or to the
|
|
|
0e076f |
HREF="mailto:cdwrite@other.debian.org">public to share your
|
|
|
0e076f |
experience.
|
|
|
0e076f |
|
|
|
0e076f |
In order to optimize seek times DVD[-ROM] players
|
|
|
0e076f |
calibrate their mechanics every time the media is loaded by sliding
|
|
|
0e076f |
the optical head some place, picking up the signal and noting the
|
|
|
0e076f |
physical block address underneath the lens. In order for this procedure
|
|
|
0e076f |
to work with re-writable/recordable media, that particular spot has to
|
|
|
0e076f |
be written to [or de-iced in DVD+RW terms]. Some units slide the head to
|
|
|
0e076f |
30mm [radial] to calibrate, some to 35mm. In order to keep such players
|
|
|
0e076f |
"happy," make sure that at least 1GB is written [before you
|
|
|
0e076f |
attempt to mount it in <NOBR>DVD-ROM</NOBR> unit].
|
|
|
0e076f |
|
|
|
0e076f |
Other units attempt to seek to lead-out [or vicinity
|
|
|
0e076f |
of it] for calibration purposes. Now the catch is that it's perfectly
|
|
|
0e076f |
possible to produce a DVD+RW disc without lead-out. Most notably media
|
|
|
0e076f |
initially formatted with <NOBR>dvd+rw-format</NOBR> [apparently]
|
|
|
0e076f |
doesn't have any lead-out, not to mention that practically whole
|
|
|
0e076f |
surface remains virgin. If you fail to mount/play DVD+RW media, attempt
|
|
|
0e076f |
to
|
|
|
0e076f |
|
|
|
0e076f |
dvd+rw-format -lead-out /dev/scd
|
|
|
0e076f |
COLOR="red">N</FONT>
|
|
|
0e076f |
|
|
|
0e076f |
which relocates the lead-out next to outermost
|
|
|
0e076f |
written sector as well as makes sure there is no virgin surface before
|
|
|
0e076f |
it. Previously written data is not affected by this operation.
|
|
|
0e076f |
|
|
|
0e076f |
"experience gathering." I mean the best I can do is to state
|
|
|
0e076f |
that my hp dvd200i unit doesn't wipe any data when relocating the
|
|
|
0e076f |
lead-out.-->
|
|
|
0e076f |
|
|
|
0e076f |
Then non-finalized DVD+R and Sequential
|
|
|
0e076f |
<NOBR>DVD-R[W]</NOBR> discs don't have lead-out either<SUP>(*)</SUP>.
|
|
|
0e076f |
If you fail to mount/play DVD+R media and wish to sacrifice the
|
|
|
0e076f |
remaining space for immediate compatibility, just fill the media
|
|
|
0e076f |
up<SUP>(**)</SUP>. Alternatively if you master volume in a single take
|
|
|
0e076f |
and don't plan to use it for multisessioning<SUP>(***)</SUP>, you have
|
|
|
0e076f |
the option to invoke growisofs with <TT>-dvd-compat</TT> option and cut
|
|
|
0e076f |
the real lead-out directly after the first session.
|
|
|
0e076f |
|
|
|
0e076f |
|
|
|
0e076f |
|
|
|
0e076f |
|
|
|
0e076f |
<FONT SIZE="-1"><SUP>(*)</SUP></FONT>
|
|
|
0e076f |
<FONT SIZE="-1">Well, there are lead-outs at the session edges, but
|
|
|
0e076f |
the problem is that "End Physical Sector Number of Data Area"
|
|
|
0e076f |
field in "Control Data Zone" of the lead-in contains address
|
|
|
0e076f |
of the largest media sector, which makes affected DVD[-ROM] players
|
|
|
0e076f |
calibrate at the outermost edge instead of the first session. Actually
|
|
|
0e076f |
I fail to understand why don't they burn the address of last sector of
|
|
|
0e076f |
the first session in the lead-in even on multisession discs...
|
|
|
0e076f |
</FONT>
|
|
|
0e076f |
|
|
|
0e076f |
|
|
|
0e076f |
<FONT SIZE="-1"><SUP>(**)</SUP></FONT>
|
|
|
0e076f |
<FONT SIZE="-1">But beware the 4GB limit!
|
|
|
0e076f |
If 4GB is already an issue, or if you don't feel like throwing
|
|
|
0e076f |
unrelated data on the media in question, then invoke '<TT>growisofs
|
|
|
0e076f |
<FONT COLOR="red">-M</FONT> /dev/scd0
|
|
|
0e076f |
COLOR="red">=/dev/zero</FONT></TT>' (supported by 5.6 and later).
|
|
|
0e076f |
Alternative is to re-master the whole volume, naturally with
|
|
|
0e076f |
<TT><NOBR>-dvd-compat</NOBR></TT> option.
|
|
|
0e076f |
|
|
|
0e076f |
files with '<TT>touch huge<FONT COLOR="red">M</FONT>.void</TT>' and
|
|
|
0e076f |
'<TT>perl -e 'truncate ("huge
|
|
|
0e076f |
COLOR="red">M</FONT>.void", 0x7ffffffe)'</TT>', and finally to
|
|
|
0e076f |
'<TT>growisofs -overburn -M /dev/scd<FONT COLOR="red">N</FONT> ...
|
|
|
0e076f |
huge*.void</TT>'. Otherwise you might have to re-master the volume with
|
|
|
0e076f |
<TT>-dvd-compat</TT> option.--></FONT>
|
|
|
0e076f |
|
|
|
0e076f |
|
|
|
0e076f |
<FONT SIZE="-1"><SUP>(***)</SUP></FONT>
|
|
|
0e076f |
<FONT SIZE="-1">E.g. when mastering DVD-Video disc:-) Note that
|
|
|
0e076f |
<TT>-dvd-video</TT> option [passed to mkisofs] engages
|
|
|
0e076f |
<TT>-dvd-compat</TT> automatically.</FONT>
|
|
|
0e076f |
|
|
|
0e076f |
|
|
|
0e076f |
|
|
|
0e076f |
|
|
|
0e076f |
Then we have logical format compatibility
|
|
|
0e076f |
issue(s). Probably the very ground for all the controversy around
|
|
|
0e076f |
DVD+RW, rather around DVD+RW media not being playable in a whole range
|
|
|
0e076f |
of players. DVD+RW Alliance was keen to blame on DVD-ROM vendors, even
|
|
|
0e076f |
claiming that they deliberately block playback. But the fact is that
|
|
|
0e076f |
format specifications don't explicitly say that unrecognized format
|
|
|
0e076f |
[designated by "Book Type" field in "Control Data
|
|
|
0e076f |
Zone" of the lead-in] should be treated as <NOBR>DVD-ROM</NOBR>
|
|
|
0e076f |
and [in my opinion] it was rather naive of them to claim and expect
|
|
|
0e076f |
that the media will be playable in "virtually all players."
|
|
|
0e076f |
This deficiency was recognized by practically all DVD+RW vendors [well,
|
|
|
0e076f |
apparently by "traditional" DVD+RW vendors and not
|
|
|
0e076f |
"latest generation" vendors such as Sony, NEC, TDK...] and a
|
|
|
0e076f |
secret vendor-specific command
|
|
|
0e076f |
manipulating this "Book Type" field was implemented. So if
|
|
|
0e076f |
you fail to mount/play DVD+RW media, you might have an option to
|
|
|
0e076f |
|
|
|
0e076f |
dvd+rw-booktype -dvd-rom -media /dev/scd
|
|
|
0e076f |
COLOR="red">N</FONT>
|
|
|
0e076f |
|
|
|
0e076f |
Once again. Not all vendors support this and you
|
|
|
0e076f |
can't expect this utility to work with all recorders.
|
|
|
0e076f |
|
|
|
0e076f |
It's naturally not possible to manipulate the
|
|
|
0e076f |
"Book Type" field on DVD+R media, that is not after the
|
|
|
0e076f |
lead-in is written [which takes place at the moment the first session
|
|
|
0e076f |
gets closed]. But it might be possible to control how it [lead-in] is
|
|
|
0e076f |
going to be branded by programming the drive in advance:
|
|
|
0e076f |
|
|
|
0e076f |
dvd+rw-booktype -dvd-rom -unit+r /dev/scd
|
|
|
0e076f |
COLOR="red">N</FONT>
|
|
|
0e076f |
|
|
|
0e076f |
Meaning that if you fail to play DVD+R media, you
|
|
|
0e076f |
can attempt to burn another disc with more appropriate unit settings.
|
|
|
0e076f |
For more background information about dvd+rw-booktype, see
|
|
|
0e076f |
HREF="http://www.dvdplusrw.org/Article.asp?aid=42&hl=bitsetting">"Compatibility
|
|
|
0e076f |
Bitsettings" article at dvdplusrw.org.
|
|
|
0e076f |
|
|
|
0e076f |
There [potentially] are other logical
|
|
|
0e076f |
DVD+RW<SUP>(*)</SUP> format incompatibilities, but the "Book
|
|
|
0e076f |
Type" issue discussed above is the only one "officially"
|
|
|
0e076f |
recognized. Well, it's actually understandable as it's the only one
|
|
|
0e076f |
that can be recognized and addressed by a DVD+RW vendor alone.
|
|
|
0e076f |
Recognition of other incompatibilities would require cooperation from
|
|
|
0e076f |
<NOBR>DVD[-ROM]</NOBR> player vendors and that's something they
|
|
|
0e076f |
apparently are not willing to show referring to the fact that DVD+RW
|
|
|
0e076f |
format is not approved [and apparently never will be] by
|
|
|
0e076f |
HREF="http://www.dvdforum.org/">DVD Forum<SUP>(**)</SUP>.
|
|
|
0e076f |
|
|
|
0e076f |
|
|
|
0e076f |
|
|
|
0e076f |
|
|
|
0e076f |
<FONT SIZE="-1"><SUP>(*)</SUP></FONT>
|
|
|
0e076f |
<FONT SIZE="-1">Finalized DVD+R media branded with
|
|
|
0e076f |
<NOBR>DVD-ROM</NOBR> "Book Type" is virtually identical to
|
|
|
0e076f |
<NOBR>DVD-ROM.</NOBR></FONT>
|
|
|
0e076f |
|
|
|
0e076f |
<FONT SIZE="-1"><SUP>(**)</SUP></FONT>
|
|
|
0e076f |
<FONT SIZE="-1">To which I say "so what?" DVD Forum is an
|
|
|
0e076f |
alliance of manufacturers just like DVD+RW Alliance is. It [or any
|
|
|
0e076f |
other party for that matter] has no authority to deny a technology
|
|
|
0e076f |
development initiative.</FONT>
|
|
|
0e076f |
|
|
|
0e076f |
|
|
|
0e076f |
|
|
|
0e076f |
|
|
|
0e076f |
Finally there is a physical incompatibility issue.
|
|
|
0e076f |
They claim that there are optical pick-ups out there not being capable
|
|
|
0e076f |
to decode the track because of low reflectivity of DVD+RW media
|
|
|
0e076f |
surface. I write "they claim," because in the lack of
|
|
|
0e076f |
cooperation from <NOBR>DVD[-ROM]</NOBR> vendors it's not possible to
|
|
|
0e076f |
distinguish physical from logical format incompatibility, which I find
|
|
|
0e076f |
important to tell apart in order to make sure at least logical format
|
|
|
0e076f |
incompatibility issues don't persist over time. It might be as trivial
|
|
|
0e076f |
as following. As you surely know [already], DVD+RW has same
|
|
|
0e076f |
reflectivity as dual-layer <NOBR>DVD-ROM.</NOBR> Now the catch is that
|
|
|
0e076f |
the linear pit density in turn is same as of single-layer one. Meaning
|
|
|
0e076f |
that if player makes assumptions about linear pit density based on
|
|
|
0e076f |
reflectivity, then it won't be able to trace the track... But either
|
|
|
0e076f |
way, there is very little you can do about this one, but to try another
|
|
|
0e076f |
player...
|
|
|
0e076f |
|
|
|
0e076f |
|
|
|
0e076f |
|
|
|
0e076f |
Technical Ramblings
|
|
|
0e076f |
|
|
|
0e076f |
|
|
|
0e076f |
|
|
|
0e076f |
|
|
|
0e076f |
ALIGN="RIGHT">
|
|
|
0e076f |
|
|
|
0e076f |
As for multisession ISO9660 [DVD]
|
|
|
0e076f |
recordings! Unfortunately, Linux ISOFS implementation had certain
|
|
|
0e076f |
deficiency which limits interoperability of such recordings. In order
|
|
|
0e076f |
to understand it, have a look at sample ISO9660 layout to the right...
|
|
|
0e076f |
Now, the problem is that isofs i-nodes<SUP>(*)</SUP> are 32 bits wide
|
|
|
0e076f |
(on a 32-bit Linux) and represent offsets of corresponding directory
|
|
|
0e076f |
entries (light-greens), byte offsets from the beginning of media. This
|
|
|
0e076f |
means that no directory (green areas) may cross 4GB boundary without
|
|
|
0e076f |
being effectively corrupted<TT>:-(</TT> It should be noted that in
|
|
|
0e076f |
reality it's a bit better than it looks on the picture, as mkisofs
|
|
|
0e076f |
collects all the directories in the beginning of any particular session
|
|
|
0e076f |
(there normally are no blues between greens). The first session
|
|
|
0e076f |
is therefore never subject to i-node wrap-around, but not the
|
|
|
0e076f |
subsequent ones! Once again, <FONT COLOR="blue">files</FONT>
|
|
|
0e076f |
themselves may reside beyond the <FONT COLOR="brown">4GB</FONT>
|
|
|
0e076f |
boundary, but not <FONT COLOR="green">the directories</FONT>, in
|
|
|
0e076f |
particular not in further sessions. Having noted that directory entries
|
|
|
0e076f |
are actually specified to start at even offsets, I figured that
|
|
|
0e076f |
it's perfectly possible to
|
|
|
0e076f |
"stretch" the limit to 8GB. But in order to assure
|
|
|
0e076f |
maximum interoperability, you should not let any session
|
|
|
0e076f |
start past 4GB minus space required for directory
|
|
|
0e076f |
structures, e.g. if the last session is to fill the media up, it
|
|
|
0e076f |
has to be >400MB. As of version 5.3 growisofs refuses to append
|
|
|
0e076f |
a new session beyond 4GB-40MB limit<SUP>(**)</SUP>, where 40MB is
|
|
|
0e076f |
pretty much arbitrary chosen large value, large for directory catalogs
|
|
|
0e076f |
that is. Yet it doesn't actually guarantee that you can't suffer
|
|
|
0e076f |
from i-node wrap-around. Interim fs/isofs 2.4
|
|
|
0e076f |
kernel patch was addressed to those who have actually ran into the
|
|
|
0e076f |
problem and have to salvage the data. Even though permanent solution
|
|
|
0e076f |
for this problem appears in Linux kernel 2.6.8 (thanks to Paul Serice
|
|
|
0e076f |
effort), growisofs keeps checking for this 4GB limit in order to ensure
|
|
|
0e076f |
broader compatibility of final DVD recordings. This check is not
|
|
|
0e076f |
performed for Blu-ray Disc recordings, as probability that a member of
|
|
|
0e076f |
such user community would run something elder than 2.6.9 is considered
|
|
|
0e076f |
diminishingly low.
|
|
|
0e076f |
|
|
|
0e076f |
|
|
|
0e076f |
|
|
|
0e076f |
<FONT SIZE="-1"><SUP>(*)</SUP></FONT>
|
|
|
0e076f |
<FONT SIZE="-1">i-node is a number uniquely identifying a single
|
|
|
0e076f |
file in a file system</FONT>
|
|
|
0e076f |
|
|
|
0e076f |
|
|
|
0e076f |
<FONT SIZE="-1"><SUP>(**)</SUP></FONT>
|
|
|
0e076f |
<FONT SIZE="-1">well, as DVD+R Double Layer support was introduced
|
|
|
0e076f |
in 5.20, <TT>-use-the-force-luke=4gms</TT> option was added to override
|
|
|
0e076f |
this behaviour (naturally recommended for Linux kernel 2.6>=8 users and
|
|
|
0e076f |
kernel developers only;-)</FONT>
|
|
|
0e076f |
|
|
|
0e076f |
|
|
|
0e076f |
|
|
|
0e076f |
|
|
|
0e076f |
|
|
|
0e076f |
Why media reload is performed after every
|
|
|
0e076f |
recording with growisofs? Well, it's performed only if you didn't
|
|
|
0e076f |
patch the kernel:-) But no, I do not insist on patching the kernel!
|
|
|
0e076f |
All I'm saying is that in the lack of kernel support, media reload is
|
|
|
0e076f |
performed for the following reasons. In order to optimize file access
|
|
|
0e076f |
kernel maintains so called block cache, so that repetitive requests for
|
|
|
0e076f |
same data are met directly from memory and don't result in multiple
|
|
|
0e076f |
physical I/O. Now the catch is that block cache layer remains totally
|
|
|
0e076f |
unaware of growisofs activities, growisofs bypasses the block
|
|
|
0e076f |
cache. This means that block cache inevitably becomes out of sync,
|
|
|
0e076f |
which in turn might appear to you as corrupted data. Media reload is
|
|
|
0e076f |
performed when flushing the block cache is not an option, e.g. only
|
|
|
0e076f |
privileged user is allowed to perform it. Second reason is to force
|
|
|
0e076f |
kernel to readjust last addressable block in case it was changed as
|
|
|
0e076f |
result of recording. This is done to preclude spurious "attempts to
|
|
|
0e076f |
access beyond end of device."
|
|
|
0e076f |
|
|
|
0e076f |
|
|
|
0e076f |
|
|
|
0e076f |
What does [kernel] "DVD+RW support"
|
|
|
0e076f |
really mean? Even though DVD+RW has no notion of [multiple]
|
|
|
0e076f |
sessions, to ensure compatibility with DVD-ROM it's essential to issue
|
|
|
0e076f |
"CLOSE TRACK/SESSION (5Bh)"
|
|
|
0e076f |
HREF="http://www.t10.org/scsi-3.htm">MMC command to
|
|
|
0e076f |
terminate/suspend background formatting (if any in progress) whenever
|
|
|
0e076f |
you intend to eject the media or simply stop writing and want better
|
|
|
0e076f |
read performance (e.g. remount file system read-only). This is what the
|
|
|
0e076f |
patch is basically about: noting when/if media was written to and
|
|
|
0e076f |
"finalizing" at unlock door.
|
|
|
0e076f |
|
|
|
0e076f |
Secondly, whenever you employ fully fledged
|
|
|
0e076f |
file system, I/O requests get inevitably fragmented.
|
|
|
0e076f |
"Fragmented" means following. Even though you can address the
|
|
|
0e076f |
data with 2KB granularity, it [data] is physically laid out in 32KB
|
|
|
0e076f |
chunks. This in turn means that for example writing of 2KB block
|
|
|
0e076f |
involves reading of 32KB chunk, replacing corresponding 2KB and writing
|
|
|
0e076f |
down of modified 32KB chunk. "Fragmented requests" are those
|
|
|
0e076f |
that are smaller than 32KB or/and cross the modulus 32KB boundaries. In
|
|
|
0e076f |
order to optimize the process certain caching algorithm is implemented
|
|
|
0e076f |
in unit's firmware. Obviously it can't adequately meet all possible
|
|
|
0e076f |
situations. And so in such unfortunate situations the drive apparently
|
|
|
0e076f |
stops processing I/O requests returning "COMMAND SEQUENCE ERROR
|
|
|
0e076f |
(2Ch)" ASC. This is the second essential of "DVD+RW
|
|
|
0e076f |
support," namely injecting of "SYNCHRONIZE CACHE (35h)"
|
|
|
0e076f |
MMC command in reply to the error condition in question. The command
|
|
|
0e076f |
flushes the cached buffers which makes it possible to resume the data
|
|
|
0e076f |
flow.
|
|
|
0e076f |
|
|
|
0e076f |
Unfortunately the above paragraph doesn't
|
|
|
0e076f |
seem to apply to the 1st generation drives, Ricoh MP5120A and
|
|
|
0e076f |
derivatives<TT>:-(</TT> "SYNCHRONIZE CACHE (35h)" doesn't
|
|
|
0e076f |
seem to be sufficient and the unit keeps replying with "COMMAND
|
|
|
0e076f |
SEQUENCE ERROR (2Ch)" going into end-less loop. This makes it
|
|
|
0e076f |
impossible to deploy arbitrary file system. I'm open for
|
|
|
0e076f |
suggestions... Meanwhile the I've chosen to simply suspend I/O till the
|
|
|
0e076f |
media is unmounted. Even 2nd gen unit were reported to exhibit similar
|
|
|
0e076f |
[but not the same] behaviour under apparently extremely rare
|
|
|
0e076f |
circumstances. At least I failed to reproduce the problem... The problem
|
|
|
0e076f |
reportedly disappears with firmware upgrade...
|
|
|
0e076f |
|
|
|
0e076f |
Then some [most?] of post-2nd gen units, from
|
|
|
0e076f |
most vendors, seem to not bother about complying with
|
|
|
0e076f |
<NOBR>DVD+RW</NOBR> specification, "true random write with 2KB
|
|
|
0e076f |
granularity" part in particular. Instead they apparently expect
|
|
|
0e076f |
host to apply procedure pretty much equivalent to <NOBR>DVD-RW</NOBR>
|
|
|
0e076f |
Restricted Overwrite. To be more specific host seems to be expected to
|
|
|
0e076f |
coalesce 2KB requests and perform aligned writes at native DVD ECC
|
|
|
0e076f |
blocksize, which is 32KB. Formally this should not be required, but
|
|
|
0e076f |
it's the reality of marketplace:-(
|
|
|
0e076f |
|
|
|
0e076f |
This one really beats me. Sometimes the unit
|
|
|
0e076f |
simply stops writing signaling a vendor specific positioning error,
|
|
|
0e076f |
03h/15h/82h to be specific. Especially if the media is newly formatted.
|
|
|
0e076f |
Couple of work theories. One is that block buffer cache reorders
|
|
|
0e076f |
requests so that they are not sequential anymore, "FLUSH
|
|
|
0e076f |
CACHE" might do the trick. Another one is that under
|
|
|
0e076f |
"underrun" condition background formatting kicks off and has
|
|
|
0e076f |
to be explicitly stopped. "Underrun" is in quotes because
|
|
|
0e076f |
the unit is supposed to handle temporary data stream outages
|
|
|
0e076f |
gracefully. If you run into this (you most likely will), try to
|
|
|
0e076f |
complement growisofs command line with [undocumented]
|
|
|
0e076f |
<TT>-poor-man</TT> option (which has to be first in the command line).
|
|
|
0e076f |
This option eliminates request reorders and minimizes possibility for
|
|
|
0e076f |
"underrun" condition (by releasing the pressure off VM
|
|
|
0e076f |
subsystem).
|
|
|
0e076f |
|
|
|
0e076f |
|
|
|
0e076f |
|
|
|
0e076f |
The original idea was to implement DVD+RW support in
|
|
|
0e076f |
drivers/cdrom/cdrom.c. Unfortunately SCSI layer maintains private
|
|
|
0e076f |
"writeable" flag controlling the ability to issue WRITE
|
|
|
0e076f |
commands. The flag is impossible to reach for from the Unified CD-ROM
|
|
|
0e076f |
driver. But why am I talking about SCSI when there are only IDE units
|
|
|
0e076f |
out there (at least for the time being)? Well, as you most likely want
|
|
|
0e076f |
to occasionally burn even CD-R[W] with cdrecord you want it to go
|
|
|
0e076f |
through ide-scsi emulation layer anyway. So I figured that SCSI CD-ROM
|
|
|
0e076f |
driver is the one to aim for even for DVD+RW.
|
|
|
0e076f |
|
|
|
0e076f |
Unfortunately it was not possible to implement it
|
|
|
0e076f |
completely in sr_mod.o<TT>:-(</TT> Minor drivers/cdrom/cdrom.c
|
|
|
0e076f |
modification was required to sense the media before decision about
|
|
|
0e076f |
whether or not to permit write open. That's because DVD+RW drives are
|
|
|
0e076f |
morphing their behaviour after currently mounted media and it's
|
|
|
0e076f |
essential to identify newly inserted media.
|
|
|
0e076f |
|
|
|
0e076f |
Special comment about "what a dirty
|
|
|
0e076f |
hack!!!" To my great surprise it turned out that time-out value you
|
|
|
0e076f |
pass in cdrom_generic_command is simply ignored and time-out is set to
|
|
|
0e076f |
pre-compiled value of 30 seconds. Unfortunately it's way too low for
|
|
|
0e076f |
formatting purposes and I had to do something about it. Alternative to
|
|
|
0e076f |
"the dirty hack" was to add another argument to sr_do_ioctl
|
|
|
0e076f |
and modify all the calls to it... I've chosen to take over those 31
|
|
|
0e076f |
unused bits from the "quiet" argument instead of modifying
|
|
|
0e076f |
all the calls (too boring).
|
|
|
0e076f |
|
|
|
0e076f |
But even if time-out value passed down to kernel
|
|
|
0e076f |
(with either CDROM_SEND_PACKET or SG_IO ioctl) is taken into
|
|
|
0e076f |
consideration, it's apparently not interpreted as user-land code
|
|
|
0e076f |
expects it to. As I figured... There is no documentation on
|
|
|
0e076f |
CDROM_SEND_PACKET, but following the common sense most programmers
|
|
|
0e076f |
(including myself:-) expect it to be interpreted in at least
|
|
|
0e076f |
platform-independent manner, such as milliseconds maybe? SG_IO timeout
|
|
|
0e076f |
in turn is
|
|
|
0e076f |
HREF="http://www.torque.net/sg/p/sg_v3_ho.html#AEN215">documented
|
|
|
0e076f |
to be measured in milliseconds... Neither of this holds true! Kernel
|
|
|
0e076f |
treats these values as "jiffies," which is a
|
|
|
0e076f |
platform-dependent value representing time elapsed between timer
|
|
|
0e076f |
interrupts. But if we attempt to send down "jiffies," it
|
|
|
0e076f |
might turn out wrong too [at least for the moment of this writing]. The
|
|
|
0e076f |
catch is that [IA-32] kernel developers figured it's cool to shorten
|
|
|
0e076f |
"jiffy," but didn't care to provide user-land with actual
|
|
|
0e076f |
value (well, not of actual interest, too much legacy code to deal with)
|
|
|
0e076f |
nor scale timeouts
|
|
|
0e076f |
accordingly in respect to the legacy value of 10ms.
|
|
|
0e076f |
|
|
|
0e076f |
There is another kernel "deficiency" I ran
|
|
|
0e076f |
into while working on the (original version of) dvd+rw-format utility.
|
|
|
0e076f |
The drive provides background formatting progress status, but
|
|
|
0e076f |
unfortunately it's impossible to access it. That's because progress
|
|
|
0e076f |
counter is returned [in reply to "TEST UNIT READY"] as
|
|
|
0e076f |
"NO SENSE/LOGICAL UNIT NOT READY/FORMAT IN PROGRESS" sense
|
|
|
0e076f |
bytes but with "GOOD" status. Apparently any sense data with
|
|
|
0e076f |
"GOOD" status is discarded by the common SCSI layer.
|
|
|
0e076f |
|
|
|
0e076f |
|
|
|
0e076f |
As you might have noticed the time-out value for
|
|
|
0e076f |
"CLOSE SESSION" is 3000 seconds. Does it really take that
|
|
|
0e076f |
long? It might... Disappointed? Don't be! It might happen only
|
|
|
0e076f |
when reformatting used media. Formatting of the blank
|
|
|
0e076f |
media doesn't take longer than a couple of minutes. Reformatting
|
|
|
0e076f |
in turn takes as long as it takes to nullify whatever you had on the
|
|
|
0e076f |
media which requires corresponding time-outs. But do you have to
|
|
|
0e076f |
reformat? Well, only if media contains sensitive data, the new data set
|
|
|
0e076f |
is smaller than the current one and (for some reason) will be easier
|
|
|
0e076f |
for potentially rival party to get hold of it (in other words when
|
|
|
0e076f |
there is a risk for sensitive data to get exposed). Another reason is
|
|
|
0e076f |
when you want to reuse the media as a master copy for DVD-ROM
|
|
|
0e076f |
manufacturing and want formatted capacity to reflect data set size.
|
|
|
0e076f |
Otherwise there is no reason to reformat and as long as you
|
|
|
0e076f |
don't you won't be disappointed with how long does it take to
|
|
|
0e076f |
"finalize" the media.
|
|
|
0e076f |
-->
|
|
|
0e076f |
|
|
|
0e076f |
It was pointed out to me that DVD+RW units work with
|
|
|
0e076f |
Acard SCSI to
|
|
|
0e076f |
IDE bridges.
|
|
|
0e076f |
|
|
|
0e076f |
|
|
|
0e076f |
|
|
|
0e076f |
What does
|
|
|
0e076f |
HREF="http://www.cdfreaks.com/article/113">plus in DVD+RW/+R
|
|
|
0e076f |
stand for? Originally this paragraph started as following:
|
|
|
0e076f |
|
|
|
0e076f |
The key feature of DVD+RW/+R media is
|
|
|
0e076f |
high [spatial] frequency wobbled [pre-]groove with addressing
|
|
|
0e076f |
information modulated into it. This makes it possible to resume
|
|
|
0e076f |
interrupted [or deliberately suspended] burning process with accuracy
|
|
|
0e076f |
high enough for DVD[-ROM] player not to "notice" anything at
|
|
|
0e076f |
playback time. Recovery from buffer underrun condition in DVD-RW/-R
|
|
|
0e076f |
case in turn is way less accurate procedure, and the problem is that
|
|
|
0e076f |
the provided accuracy is very much what average player can tolerate.
|
|
|
0e076f |
Now given that both provided and tolerated inaccuracies are
|
|
|
0e076f |
proportional to respectively writing and reading velocities there
|
|
|
0e076f |
basically no guarantee that DVD-RW/-R recording that suffered from
|
|
|
0e076f |
buffer underrun will be universally playable.
|
|
|
0e076f |
|
|
|
0e076f |
Well, it turned out that I was wrong about one
|
|
|
0e076f |
thing.
|
|
|
0e076f |
to DVD-R[W] to be specific.--> I failed to recognize that DVD-R[W]
|
|
|
0e076f |
groove also provides for adequately accurate recovery from
|
|
|
0e076f |
buffer underrun condition/lossless linking. Not as accurate as DVD+RW,
|
|
|
0e076f |
but accurate enough for splices to be playable in virtually any
|
|
|
0e076f |
DVD-ROM/-Video unit. Yet! When it comes to DVD-R[W] recording
|
|
|
0e076f |
specificaton apparently insists that you choose between
|
|
|
0e076f |
|
|
|
0e076f |
|
|
|
0e076f |
buffer underrun protection and
|
|
|
0e076f |
full DVD-ROM/-Video compatibility.
|
|
|
0e076f |
|
|
|
0e076f |
|
|
|
0e076f |
The specification asserts that the latter is
|
|
|
0e076f |
achieved only in Disc-at-once recording mode and only if data-stream
|
|
|
0e076f |
was maintained uninterrupted throughout whole recording. Once again.
|
|
|
0e076f |
Even though most vendors implement lossless linking in DAO
|
|
|
0e076f |
mode<SUP>(*)</SUP>, full DVD-ROM/-Video compatibility is
|
|
|
0e076f |
guaranteed only if recording didn't suffer from buffer underruns. The
|
|
|
0e076f |
problem is that "offended" sectors are denoted with certain
|
|
|
0e076f |
linking chunk appearing as degraded user data, few bytes, which
|
|
|
0e076f |
are supposed to be "corrected away" by ECC
|
|
|
0e076f |
procedure<SUP>(**)</SUP>. DVD+ splices are in turn only few bits large
|
|
|
0e076f |
and are "accounted" to sync patterns, not to user data
|
|
|
0e076f |
area. So that even if suffered from buffer underrun, DVD+ sector is
|
|
|
0e076f |
logically indistiguishable from DVD-ROM. Which is why it's commonly
|
|
|
0e076f |
referred to that DVD+RW/+R combine DVD-ROM/-Video compatibility with
|
|
|
0e076f |
[unconditional] buffer underrun protection.
|
|
|
0e076f |
|
|
|
0e076f |
As already mentioned, DVD+ groove has
|
|
|
0e076f |
"addressing information modulated into it," ADIP (ADress In
|
|
|
0e076f |
Pre-groove). This gives you an advantage of writing DVD+RW in truly
|
|
|
0e076f |
arbitrary order, even to virgin surface and practically instantly
|
|
|
0e076f |
(after ~40 seconds long initial format procedure). In addition, DVD+RW
|
|
|
0e076f |
can be conveniently written to with 2KB granularity<SUP>(***)</SUP>.
|
|
|
0e076f |
DVD-RW in turn can only be overwritten in arbitrary order.
|
|
|
0e076f |
Meaning that it either has to be completely formatted first (it takes
|
|
|
0e076f |
an hour to format 1x media), or initially written to in a sequential
|
|
|
0e076f |
manner. And it should also be noted that block overwrite is
|
|
|
0e076f |
never an option if DVD-RW media was recorded in [compatible]
|
|
|
0e076f |
Disc-at-once or even Incremental mode, only whole disc blanking is.
|
|
|
0e076f |
|
|
|
0e076f |
Unlike DVD-R[W], DVD+R[W] recordings can be
|
|
|
0e076f |
suspended at any time without any side effects. Consider following
|
|
|
0e076f |
scenario. You have a lot of data coming in [at lower rate], which is to
|
|
|
0e076f |
be recorded into one file. Meanwhile it turns out that you have to
|
|
|
0e076f |
retrieve previously recorded data. This would naturally require
|
|
|
0e076f |
suspention of recording. Most notably in DVD-R [and naturally DVD-RW
|
|
|
0e076f |
Sequential] case it would result in a hole in the file being recorded.
|
|
|
0e076f |
So called linking area, most commonly 32KB gap, has to be introduced.
|
|
|
0e076f |
So that you either have to wait till the file is complete or figure out
|
|
|
0e076f |
how to deal with holey files. Thanks to ADIP, DVD+R recording is
|
|
|
0e076f |
resumed from the very point it was suspended at. In DVD-RW Restricted
|
|
|
0e076f |
Overwrite case no gaps are introduced, but if the media was formatted
|
|
|
0e076f |
only minimally, suspension/resuming procedure has to be applied and it
|
|
|
0e076f |
takes ~40 seconds to perform one. In DVD+RW case, suspension/resuming
|
|
|
0e076f |
is instant regardless media state.
|
|
|
0e076f |
|
|
|
0e076f |
What does all of the above mean in practice? Well, I
|
|
|
0e076f |
was actually hoping that readers would [be able to] figure it out by
|
|
|
0e076f |
themselves. Apparently a couple of "guiding" words are
|
|
|
0e076f |
needed... It means that it's trivial to employ DVD+RW for housing of
|
|
|
0e076f |
live and arbitrary file system, no special modifications to target file
|
|
|
0e076f |
system driver are required... Real-time VBR (Variable Bit Rate) Video
|
|
|
0e076f |
recordings are children's game...
|
|
|
0e076f |
|
|
|
0e076f |
Sometimes DVD+RW/+R recording strategy is referred
|
|
|
0e076f |
to as packet writing. I myself am reluctant to call it so (or
|
|
|
0e076f |
TAO/SAO/DAO) for the following reason. Despite the fact that DVD-R[W]
|
|
|
0e076f |
provides for lossless linking (within a packet/extent only),
|
|
|
0e076f |
packets/extents are still denoted with certain linking information
|
|
|
0e076f |
which distinguishes it (recording mode in question) from e.g.
|
|
|
0e076f |
Disc-at-once. Now the point is that written DVD+RW/+R media, rather its
|
|
|
0e076f |
Data Zone, does not contain any linking information and is
|
|
|
0e076f |
logically indistinguishable from one written in DVD-R[W] Disc-at-once
|
|
|
0e076f |
mode (or DVD-ROM for that matter).
|
|
|
0e076f |
|
|
|
0e076f |
It's maintained that signal from DVD+ groove (the
|
|
|
0e076f |
one essential for recording, not reading) is much stronger, which makes
|
|
|
0e076f |
it quite resistant to dust, scratches, etc.
|
|
|
0e076f |
|
|
|
0e076f |
Now we can also discuss differences between
|
|
|
0e076f |
Double/Dual Layer implementations. DVD+R Double Layer permits for
|
|
|
0e076f |
arbitrary layer break positioning yet maintaining contiguous logical
|
|
|
0e076f |
block addressing. In other words address of the block following the
|
|
|
0e076f |
break is always address of the block preceding one plus 1, even for
|
|
|
0e076f |
arbitrarily positioned break. <NOBR>DVD-R</NOBR> Dual Layer on the
|
|
|
0e076f |
other hand implies unconditionally disjoint logical block addressing
|
|
|
0e076f |
[for arbitrarily positioned layer break that is]. This is because block
|
|
|
0e076f |
addresses as recorded by unit are pre-defined by <NOBR>DVD-dash</NOBR>
|
|
|
0e076f |
groove structure. In practice it means that file system layout has to
|
|
|
0e076f |
effectively have a hole, which "covers" twice the space between chosen
|
|
|
0e076f |
layer break position and outermost edge of the recordable area. And in
|
|
|
0e076f |
even more practical terms this means that mastering programs have to be
|
|
|
0e076f |
explicitly adapted for <NOBR>DVD-R</NOBR> layer break positioning.
|
|
|
0e076f |
Unlike DVD+plus that is.
|
|
|
0e076f |
|
|
|
0e076f |
|
|
|
0e076f |
|
|
|
0e076f |
|
|
|
0e076f |
<FONT SIZE="-1"><SUP>(*)</SUP></FONT>
|
|
|
0e076f |
<FONT SIZE="-1">According to
|
|
|
0e076f |
HREF="ftp://ftp.avc-pioneer.com/Mtfuji_6/Spec/">Mt. Fuji draft
|
|
|
0e076f |
buffer underrun protection is not even an option in DVD-R DAO: "If a
|
|
|
0e076f |
buffer under-run occurs, the logical unit shall stop
|
|
|
0e076f |
writing immediately and the logical unit shall start
|
|
|
0e076f |
writing of Lead-out." Protection is defined in Incremental Sequential
|
|
|
0e076f |
mode and DVD-RW context. By the way, note that earlier versions of this
|
|
|
0e076f |
draft also discuss DVD+RW. You should be aware that they refer to
|
|
|
0e076f |
abandoned version which has very little to do with DVD+RW/+R
|
|
|
0e076f |
implementation being discussed here.</FONT>
|
|
|
0e076f |
|
|
|
0e076f |
<FONT SIZE="-1"><SUP>(**)</SUP></FONT>
|
|
|
0e076f |
<FONT SIZE="-1">ECC redundancy does permit for more degradation,
|
|
|
0e076f |
more that this linking chunk that is, so that it hadly affects the
|
|
|
0e076f |
playability.</FONT>
|
|
|
0e076f |
|
|
|
0e076f |
<FONT SIZE="-1"><SUP>(***)</SUP></FONT>
|
|
|
0e076f |
<FONT SIZE="-1">DVD "native" block size is 32KB, and 2KB
|
|
|
0e076f |
granularity is nothing but a trick, but you're excused from playing it,
|
|
|
0e076f |
i.e. reading 32KB, replacing corresponding 2KB and writing 32KB
|
|
|
0e076f |
back.</FONT>
|
|
|
0e076f |
|
|
|
0e076f |
|
|
|
0e076f |
|
|
|
0e076f |
|
|
|
0e076f |
<SPACER TYPE="block" WIDTH="100%" HEIGHT="100%">
|
|
|
0e076f |
|
|
|
0e076f |
</BODY>
|
|
|
0e076f |
</HTML>
|