index.html

最新的linux下dvd刻录软件,支持DVD+RW、DVD-RW光盘刻录。

<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 &quot;session&quot; 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). If you consider passing <TT>/same/files</TT> as argument, or in
other words consider deploying growisofs for <I>incremental</I>
multisession backups, then you shall find <A
HREF="mkisofs-2.01a16-root.diff">this '-old-root' extension</A> to
mkisofs <FONT COLOR="red">2<A
HREF="mkisofs-2.0-root.diff">.</A>0-2.01</FONT> simply indispensable.
The idea and implementation by <A
HREF="http://home.pages.de/~ohly/#mkisofs-root">Patrick Ohly</A> is to
&quot;graft&quot; recording sessions as separate directories. Each
backup increment/directory is ment to contain both updated files and
<I>references</I> to previously backed up ones, which facilitates
comparison between increments as well as fine-graded restore.

<P ALIGN="justify">Number of users asked about opposite to
multisessioning: multivolume support. Being essentially a recording
program growisofs does not support multiple volumes by itself. There're
couple of front-ends I can recommend that arrange for this: <A
HREF="http://scdbackup.sourceforge.net/main_eng.html">scdbackup</A> and
<A HREF="http://www.serice.net/shunt/">shunt</A>. But back to
growisofs...

<P ALIGN="JUSTIFY"><B>In addition to intuitive -Z interpretation,</B>
growisofs [version 3.3 and later] recognizes special form of -Z command
line option which permits burning of arbitrary pre-mastered images. The
&quot;magic&quot; 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 <I>arbitrary
object</I> in the file system, such as file, named pipe or device
entry. No, nothing is &quot;growing&quot; here and command name is
counter-intuitive in this particular context. And here is even less
intuitive<TT>:-)</TT> If you wish to burn down 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 BD-R/DVD&plusmn;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&plusmn;R media does have notion of multiple
sessions. <I>However!</I> Not all legacy units can &quot;see&quot;
beyond the first one. Few DVD-ROM units are capable of DVD-R
multiborder playback, even fewer support DVD+R multisessioning. In
other words  your DVD burner might be the only unit in your vicinity
capable to access data added at different occasions.

<LI>Even if your DVD unit does &quot;sense&quot; multiple sessions,
Linux kernel [2.4] 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 corresponding driver, most likely
'<TT>rmmod sr_mod</TT>'.

<LI>Linux kernel 2.6&lt;<A
HREF="http://marc.theaimsgroup.com/?l=linux-kernel&m=110330852622064&w=2">10</A>
users might experience <A
HREF="http://marc.theaimsgroup.com/?l=linux-kernel&m=108827602322464&w=2">problems
mounting multisession media</A> with last session starting beyond
2.2GB boundary. As fast-acting remedy I can suggest to route your unit
through ide-scsi, the way it was under 2.4. Even though it's declared
unsupported it actually still works in 2.6 (I for one still use it).

<LI>If you go for BD-R/DVD&plusmn;R multisessioning, 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>.

<LI>And when it comes to <B>DVD+R Double Layer and <NOBR>DVD-R</NOBR>
Dual Layer recordings,</B> growisofs applies yet another limitation,
purely artificial. Taking into consideration Double Layer media prices
growisofs is programmed to <B>refuse to perform <I>unappendable</I>
recordings which are less than 1/2 of blank capacity</B> and to advice
to use single layer media instead.

<LI>DVD-R Dual Layer multisessioning is not supported for a reason
discussed on the <A HREF="-RW/#nomultisess">-RW companion page</A>. Once
again, as of the moment of this writing <NOBR>DVD-R</NOBR> Dual Layer
recordings come out unappendable and can not be grown.
</UL>


<P ALIGN="justify">And once again, do keep in mind that 4.7GB are
salesman's&nbsp;GB, i.e. 1000<SUP>3</SUP> and not 1024<SUP>3</SUP>. If
translated to &quot;real&quot;&nbsp;GB, single layer
<NOBR>DVD&plusmn;R[W]</NOBR> capacity is not larger than 4.4GiB, and BD
- not larger than 23.3GiB! It should also be noted that earlier
growisofs versions did not check if there is enough space on media to
accommodate the data set to be burned, meaning that it was your sole
responsibility to make sure &quot;overburn&quot; condition is not
raised. As of version&nbsp;5.2 growisofs performs the necessary checks
for you and refuses to start recording if &quot;overburn&quot;
condition appears to be unavoidable. This behaviour can be overridden
with <TT>-overburn</TT> command-line option.

<P><LI><P ALIGN="justify">If you're satisfied with growisofs, then you
should <B>just proceed to <A HREF="#compat">the next chapter</A></B>
and abstain from applying the <B>optional 2.4.x kernel patch.</B> 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>. As you could
have noticed, patch targets SCSI CD-ROM module. This means that you
<I>have to</I> "route" your IDE unit through ide-scsi to get this one
working. 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 &quot;<TT>sr<FONT
COLOR="red">N</FONT>: mmc-3 profile: 1Ah</TT>&quot. 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 &quot;<TT>sr<FONT
COLOR="red">N</FONT>: dirty DVD+RW media</TT>.&quot

<!--<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.-->
	
<P ALIGN="JUSTIFY"><B>Linux 2.6</B> DVD+RW kernel support is planned in
line with DVD+MRW kernel support. This [unfortunately] means that
industry has to deliver a DVD+MRW capable unit first. Yes, the last
sentence means that despite all the promises, there are no such units
available on the market yet. As of the 1st of August 2003, Ricoh MP5240A,
Philips DVDRW416K or BenQ DW400A do <B>not</B> actually implement
Mt.Rainier/EasyWrite support. It remains to be seen if they will offer
it in form of firmware upgrade. In either case, the [original] project
goal is not only read-write support for DVD+[M]RW capable units
themselves, but even playback of DVD+MRW formatted media in legacy
DVD-ROM units (when defect list will be read and interpreted by OS
software in opposite to Mt.Rainier firmware).

<A NAME="udf"><P><LI></A><P ALIGN="justify">Even though kernel now
permits to build and mount arbitrary file system, 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. The thing about fully fledged file systems
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 &quot;costs&quot; 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 &quot;budget&quot; way sooner]... Defect management
[in firmware, a.k.a. <A
HREF="http://www.licensing.philips.com/information/mtr/">Mt.Rainier</A>,
or at file system level] would improve the situation, but ideally
file system driver should definitely refrain from modifying the
super-block [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 optimization. This paragraph
applies only if you've patched the kernel. As some of you might
remember the original recommendation was &quot;do use <TT>obs=32k</TT>
for optimal performance.&quot; Well, it was rather naive of me to say
so, as common block device layer <I>completely</I> reorganizes the
stream so that '<TT>&gt;/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 (as well as most other programs, e.g. tar) won't work as
/dev/raw expects specifically aligned buffer... As <I>temporary</I>
workaround, just to get you going so that you can start figuring things
out, consider <A
HREF="http://fy.chalmers.se/~appro/LD_*-gallery/index.html?aligned_io#aligned_io">this
&quot;hacklet&quot;</A>...

</UL>

<A NAME="compat"><P><HR></A>

<H3>Compatibility: caveat lector</H3>

<P><HR WIDTH="50%" ALIGN="LEFT">

<P ALIGN="JUSTIFY">This paragraph discusses &quot;DVD-ROM
compatibility,&quot; or playability of already recorded media in legacy
units. Blank media compatibility issues, or cases such as failure to
start or fulfill recording because of poor media support by burner
firmware, are beyond the current scope. Turn to your vendor for list of
supported media and/or to the <A
HREF="mailto:[e-mail]">public</A> to share your
experience.

<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 re-writable/recordable media, that particular spot has to
be written to [or de-iced in DVD+RW terms]. Some units slide the head to
30mm [radial] to calibrate, some to 35mm. In order to keep such players
&quot;happy,&quot; make sure that at least 1GB is written [before you
attempt to mount it in <NOBR>DVD-ROM</NOBR> unit].

<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 disc without lead-out. Most notably media
initially formatted with <NOBR>dvd+rw-format</NOBR> [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 is <B>not</B> affected by this operation.