Thursday, December 10, 2009

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

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

by <>, March 2008

Q. What is this page (not) about?
A.  Maybe to your disappointment it is not about video(*). The scope of this page is primarily computer storage applications of Blu-ray Disc and DVD±RW/±R, things like backup, archiving, data exchange... The downloadable files are an optional [and essentially historical] Linux 2.4 kernel DVD+RW patch and a couple of user-land utilities dubbed as dvd+rw-tools.

(*) Though it doesn't mean that you can't burn DVD-Video discs with dvd+rw-tools. [Unlike Video-CD] DVD-Video is "molded" in an ordinary data file system and therefore no explicit support by the burning program is actually required. In other words it is the DVD-Video content preparation which is beyond the scope of this page.

Q. Kernel patch? What would it be good for?
A. It should be explicitly noted that the user-land utilities, dvd+rw-tools, do suffice for BD/DVD recording without explicit kernel support. So if they fulfill your requirements, then patching the kernel is by all means optional. Kernel support would make it possible to house a read-write file system, e.g. udf, vfat, ext2, etc. and accomodate "live" data on suitable optical media. However, I have to recommend to deploy it with caution, see tutorial for further details. Above mentioned 2.4 patch is provided mostly for historical reasons. Linux kernel version 2.6>=10 is equipped with packet writing driver which supports even DVD rewritable media, but I haven't tested it myself, so don't ask:-)

Q. What are the dvd+rw-tools for?
A. As implied/already mentioned - to master the Blu-ray Disc and DVD media, both +RW/+R and -R[W]. I could simply refer to the tutorial below, but figured that couple of words about the [original] design ideas behind growisofs, the principal burning utility, wouldn't harm. Even though a modified kernel can let you put for example an ext2 file system on DVD+RW, it's probably not very practical, because you most likely want to access the data on an arbitrary computer. Or in other words you most likely want ISO9660. The trouble is that you might as well want to add data now and then. And what options do you have in the lack of multiple sessions (no, DVD+RW has no notion of multiple sessions)? Complete re-mastering which takes more and more time as data set grows? Well, yes, unless you employ growisofs! Growisofs provides the way to both lay down and grow an ISO9660 file system on (as well as to burn an arbitrary pre-mastered image to) all supported optical media.

Q. But if they support both + and - recording strategies, why are they called dvd+rw-tools?
A. For historical/nostalgical reasons, as originally they did support exclusively DVD+plus. On the other hand now, when the vast majority of DVD burners that are being introduced to the market today are DVD+capable, the name most likely refers to your unit in either case. And you can always consider the plus in the name as notion of a unique quality, such as "seamless" multisessioning, not as reference to some particular format:-)

Q. Do I still need cdrtools?
A. Yes. It should be explicitly noted that growisofs is a front-end to mkisofs, i.e. invokes mkisofs to perform the actual ISO9660 file system layout. Secondly, the DVD burners available on the market can burn even CD-R[W] media and cdrecord is the tool for this job.
Q. There are dual-format DVD+RW/-RW units available on the market, e.g. SONY DRU500. Can I use dvd+rw-tools with it/them?
A. 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 experimental support even for recording of DVD-R[W] media and refer you to a dedicated page for further details.

Q. Does it work with my recorder unit?
A. If your unit is MMC compliant, then the answer is "most likely it just does." Well, as the probability of your unit being non-MMC compliant is virtually zero, the answer in practice is unconditionally "most likely." The [core] tools were reported to work with a wide range of drives, including [but not limited to] HP dvd[12345]x0i, Ricoh MP512x, Philips DVDRW[248]xx, SONY DRU-[157]x0, NEC ND-[1234]xx0, TDK indiDVD 4x0N, Plextor PX-[57]xx, Benq DW[48]00A, OptoRite DD0[24]0x, Lite-On LDW-[4816]xxS, as well as nonplus units such as Pioneer DVR-x0[45679], LG GxA-40[248]x, Toshiba SD-R[56]112, Panasonic UJ-811, LF-D[35]1x, and not the least all-mighty SW-5582...

Q. Is there a GUI front-end available for dvd+rw-tools?
A. K3b, version 0.10 and later, and nautilus-cd-burner, version 0.5.1 and later, are both hiding growisofs behind their pretty buttons and menus:-) Keep in mind that those are not directly related to dvd+rw-tools development effort and GUI users should turn elsewhere for end-user support. Oh! dvd+rw-tools 5.10.x is a minimum requirement for GUI frontends...

Q. I don't run Linux. What are my options?
A. Version 5.4 adds support for OpenBSD/NetBSD. Version 5.6 adds support for Solaris 2.x [commercial licensing terms for distribution on Solaris are to be settled with Inserve Technology]. Version 5.8 features FreeBSD port contributed by Matthew Dillon, FreeBSD Development Team alumnus. Hewlett-Packard Company has donated HP-UX 11 support for 5.14(*). IRIX 6.x support appears in 5.19, Win32 one - in 6.0, while Mac OS X - in 7.0...

¡ Common usage tip! Whenever separately available [and unless stated otherwise], do use character-type device entry with dvd+rw-tools, e.g. OpenBSD/NetBSD users should stick to /dev/rcdXc.
FreeBSD tip! If you have an IDE unit, atapicam is your mantra! Secondly, if you have devfs mounted, you might have to mount fdescfs as well.
(*) As of 5.14 HP-UX support was classified as "initial." Version 5.18 in turn is the one which has undergone HP quality assurance testing and is delivered on HP software depot.


As of May 2003 I've decided to advise users to turn to <> on support matters. It's an open list, meaning that you don't have to be subscribed to post a problem report. List archives can be found at both subscribe page and When submitting report, provide versioning information, exact command line, exact output generated by the program and complement it with dvd+rw-mediainfo output for resulting recording. Do check couple of last archived months, as the issue might have been discussed recently. If you've chosen to contact me personally and haven't heard back within a week or so, then you most likely overlooked something on this page. Please read it more attentively...

Special thanks for hardware donations [in chronological order]:


  • If your burner unit is managed by some Linux(*) removable media automounting/autoplaying facility, such as autofs, supermount, subfs/submount, magicdev, autorun or similar, take it out of its control! I can't help you with the latter, check your system documentation (such as google perhaps:-) for specific instructions. Failure to take your unit out of Linux(*) automounting/autoplaying facility control can result in busted recording, a coaster! At the very least you have to make sure your unit is not automounted during recordings.

    (*) dvd+rw-tools support Solaris volume manager and IRIX mediad in more gracious manner and it's safe to leave recorder under their control.

  • Remember to consult Hardware Compatibility Notes for possible caveats or vendor-specific instructions for your unit. Well, such reminder belongs at the end of tutorial, but I consider it important enough to bring it up already here:-)

  • If you have an IDE unit and run 2.4.x kernel, you most likely want to "route" it through ide-scsi emulation layer by either:

    • passing "hdX=ide-scsi" argument to kernel;
    • appending following lines to your /etc/modules.conf:
      options ide-cd ignore=hd
      X pre-install sg modprobe ide-scsi pre-install sr_mod modprobe ide-scsi pre-install ide-scsi modprobe ide-cd

    Keep in mind that once hdX is routed through ide-scsi, you can no longer refer to /dev/hdX(*), but to corresponding /dev/scdN only.

    (*) well, except as in hdparm -d [0|1] /dev/hdX. As for DMA settings. Several users of NEC[-based] units have reported that their systems crash during DVD recording. The problem appears to be related to DMA settings, at least switching it off reportedly helps. The problem appears to be specific to some IDE chipsets...

  • If you have an external unit, just get it working as CD-ROM first. I myself have limited experience with USB or IEEE1394/Firewire optical storage devices and have to direct you elsewhere for specific instructions. I however am confident that if you manage to get your drive working reliably as CD-ROM and CD-R[W] burner, then you won't have any troubles with dvd+rw-tools either. USB connected drives were reported to be working fine since eternity. Firewire connected drives in turn were reported to fail miserably under 2.4.18. The failure didn't seem to be DVD recording related as it reportedly failed burning even CD-R media. Firewire support was substantially revamped in 2.4.19, and dvd+rw-tools were reported to work with this and later kernels.

  • If you're running 2.4.19 or .20, consider applying this drivers/scsi/sg.c patch. The bug is fixed in .21. I write "consider" and not "do" for the following reasons:

    • dvd+rw-tools are not affected by this bug (as they don't use SG_IO interface), cdrecord [potentially] is;
    • 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;

    As of version 5.6 dvd+rw-tools add support for SG_IO pass-through or in other words support for Linux 2>=5[.43], where "generic" SCSI interface can be bypassed by issuing SG_IO ioctl directly against block device, such as /dev/hdX. I wish it worked without need for interim patches #1 and #2, (the latter is relative to 2.5.69-75, the 1st problem is addressed in .71, 2nd one - .75-bk3 in "last minute" prior first 2.6 cut. As for 2.6 in more general sense. As you can imagine this new interface renders ide-scsi layer superfluous and "the[ir] official plan™" is to scrap it. I'm not really fond of the idea, but not for /dev/sg* account. I mean I [personally] would prefer to keep ide-scsi and use SG_IO pass-through with /dev/scdN, rather than with /dev/hdX:-)

    If you have to make dvd+rw-tools work under Linux kernel 2.6.8, then upgrade the tool-chain to 5.21.x or later and manually reward the installed binaries with set-root-uid flag. But the "supported" recommendation is to just stay away from this particular kernel version. As for 2.6>8, dvd+rw-tools 5.21.x is requirement. Oh! dvd+rw-booktype utility would require set-root-uid privilege then. Given its semi-official status and the fact that this utility works only with limited number of units, installation procedure abstains from installing dvd+rw-booktype set-root-uid, leaving this security sensitive choice to the end-user.

  • Download, unpack and compile the the tool-chain. To build the thing do pick the .tar.gz archive, which contains Makefile as well as .spec file. You will need both C and C++ compilers installed. Separate source code files found in the download catalog are provided mainly for on-line reference purposes (such as revision history:-).

    If your Linux kernel supports multiple ABIs (e.g. Linux-sparc64 can run even 32-bit Linux-sparc applications, as well as Linux-x86_64 can execute legacy 32-bit i386 binaries), make sure you compile for native 64-bit ABI (which can normally be done with 'make TARGET_ARCH=-m64'). The problem here is that 64-bit kernel has to explicitly convert ioctl structures passed by 32-bit applications and apparently it does really lousy job when it comes to CDROM_SEND_PACKET ioctl deployed by dvd+rw-tools.

  • As new media products and brands are being introduced to the market all the time, it apparently pays off to periodically check for firmware updates. For elder units firmware update might even be an absolute requirement for using new media. Special note for HP users. HP no longer posts firmware updates on a web-page. Instead they let some Windows auto-update gizmo to pick firmware updates among dvd[1-6]00*.exe files in their FTP directory, so that readers of this page tend to miss them...

  • Formatting the BD and DVD+RW media. Virgin BD and DVD+RW media needs to be initally formatted prior usage. Once again, only virgin BD and DVD+RW media needs to be formatted. As of version 5.10 growisofs detects blanks and applies initial formatting procedure automatically. Otherwise same effect can be achieved by passing the device name, e.g. /dev/scd0, as an argument to dvd+rw-format. Though in BD case it does offer more flexibility than growisofs. To make formatting process reasonably fast, less than 1 minute, the media gets formatted only partially, as you can notice by observing progress indicator displayed by dvd+rw-format. 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 transparently, as you add more data. Oh! Do keep in mind that DVD capacity of 4.7GB is expressed in salesman's GB, i.e. 10003 and not 10243. And so is one of BD.

    It was observed that excessive reformats can render DVD+RW media unusable already after 10-20 reformats. It appears to be a firmware deficiency, not some common media defect [at least it was perfectly possible to salvage the media in a unit of different brand], but I don't recommend [enforced] reformat in either case.

    Note that re-formatting procedure does not substitute for blanking. If you want to nullify the media, e.g. for privacy reasons, do it explicitly with 'growisofs -Z /dev/scdN=/dev/zero'. Otherwise just write over previous recording as it simply wasn't there, no re-formatting is required. 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.--->

  • Burning with growisofs. There is hardly a need for manual for growisofs. 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, should] consult mkisofs manual page and accompanying reference documentation (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:-). Differences from mkisofs command line are:

    • you may not use -o option;
    • you don't have to specify -C option, growisofs will construct one for you;
    • there is internal -Z option for initial session recording, this substitutes for originally suggested 'mkisofs | dd of=/dev/scd0';

    Otherwise everything 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.:

    growisofs -Z /dev/scd0 
    -R -J /some/files growisofs -M /dev/scd0 -R -J /more/files

    Oh! Do make sure you have at least mkisofs 1.14 on your $PATH (mkisofs 1.14 is part of cdrtools 1.10). If you consider passing /same/files as argument, or in other words consider deploying growisofs for incremental multisession backups, then you shall find this '-old-root' extension to mkisofs 2.0-2.01 simply indispensable. The idea and implementation by Patrick Ohly is to "graft" recording sessions as separate directories. Each backup increment/directory is ment to contain both updated files and references to previously backed up ones, which facilitates comparison between increments as well as fine-graded restore.

    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: scdbackup and shunt. But back to growisofs...

    In addition to intuitive -Z interpretation, growisofs [version 3.3 and later] recognizes special form of -Z command line option which permits burning of arbitrary pre-mastered images. The "magic" command is:

    growisofs -Z /dev/scd0

    where image.iso represents an arbitrary object in the file system, 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:-) If you wish to burn down output generated by an arbitrary program, you can use:

    dumpsomething | growisofs -Z /dev/scd0=

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

    • Needless to say that you have only one shot with -Z option:-) 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:-) --->
    • Unlike DVD+RW, DVD±R media does have notion of multiple sessions. However! Not all legacy units can "see" 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.
    • Even if your DVD unit does "sense" multiple sessions, Linux kernel [2.4] sometimes fails to pull that information from the drive:-( Till the problem is looked into and resolved you can work it around by reloading corresponding driver, most likely 'rmmod sr_mod'.
    • Linux kernel 2.6<10 users might experience problems mounting multisession media 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).
    • If you go for BD-R/DVD±R multisessioning, you have to use mkisofs from cdrtools-2.0 or later or apply this patch.
    • And when it comes to DVD+R Double Layer and DVD-R Dual Layer recordings, growisofs applies yet another limitation, purely artificial. Taking into consideration Double Layer media prices growisofs is programmed to refuse to perform unappendable recordings which are less than 1/2 of blank capacity and to advice to use single layer media instead.
    • DVD-R Dual Layer multisessioning is not supported for a reason discussed on the -RW companion page. Once again, as of the moment of this writing DVD-R Dual Layer recordings come out unappendable and can not be grown.

    And once again, do keep in mind that 4.7GB are salesman's GB, i.e. 10003 and not 10243. If translated to "real" GB, single layer DVD±R[W] 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 "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 overridden with -overburn command-line option.

  • If you're satisfied with growisofs, then you should just proceed to the next chapter and abstain from applying the optional 2.4.x kernel patch. If you haven't stopped reading beyond this line, download 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 me how. As you could have noticed, patch targets SCSI CD-ROM module. This means that you have to "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, 'dd if=/dev/scdN count=0' would do. Then verify that kernel logs "srN: mmc-3 profile: 1Ah". You should now be able to 'mkisofs -pad . | dd of=/dev/scdN obs=32k' or even 'mke2fs -b 2048 /dev/scdN' and observe kernel logging "srN: dirty DVD+RW media." If you have previous patch version applied, then you have to back it out first. The simplest way is probably to restore drivers/scsi/sr*.[ch] and drivers/cdrom/cdrom.c from your original Linux source code ditribution.-->

    Linux 2.6 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 not 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).

  • Even though kernel now permits to build and mount arbitrary file system, there is one thing you must keep in mind before you just proceed, no matter how tempting it might appear.

    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 noatime 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 [supermount would exhaust the "budget" way sooner]... Defect management [in firmware, a.k.a. Mt.Rainier, 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 Linux UDF 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 SourceForge and build the module separately. Of course you will have to fetch and build udftools as well. But once it's done just type:

    mkudffs --spartable=2 --media-type=cdrw /dev/scd
    N mount -o rw,noatime /dev/scdN /mnt/cdrom

    mkudffs command line options were suggested by UDF maintainer, Ben Fennema.

  • Performance optimization. This paragraph applies only if you've patched the kernel. As some of you might remember the original recommendation was "do use obs=32k for optimal performance." Well, it was rather naive of me to say so, as common block device layer completely reorganizes the stream so that '>/dev/scd0' is as good as '|dd of=/dev/scd0 obs=32k'. 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. 'raw /dev/raw/raw1 /dev/scd0', 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 temporary workaround, just to get you going so that you can start figuring things out, consider this "hacklet"...

  • Compatibility: caveat lector

    This paragraph discusses "DVD-ROM compatibility," 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 public to share your experience.

    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 "happy," make sure that at least 1GB is written [before you attempt to mount it in DVD-ROM unit].

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

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

    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 not affected by this operation.

    Then non-finalized DVD+R and Sequential DVD-R[W] discs don't have lead-out either(*). If you fail to mount/play DVD+R media and wish to sacrifice the remaining space for immediate compatibility, just fill the media up(**). Alternatively if you master volume in a single take and don't plan to use it for multisessioning(***), you have the option to invoke growisofs with -dvd-compat option and cut the real lead-out directly after the first session.

    (*) 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 multisession discs...
    (**) But beware the 4GB limit! If 4GB is already an issue, or if you don't feel like throwing unrelated data on the media in question, then invoke 'growisofs -M /dev/scd0=/dev/zero' (supported by 5.6 and later). Alternative is to re-master the whole volume, naturally with -dvd-compat option. touch hugeM.void' and 'perl -e 'truncate ("hugeM.void", 0x7ffffffe)'', and finally to 'growisofs -overburn -M /dev/scdN ... huge*.void'. Otherwise you might have to re-master the volume with -dvd-compat option.-->
    (***) E.g. when mastering DVD-Video disc:-) Note that -dvd-video option [passed to mkisofs] engages -dvd-compat automatically.

    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 explicitly 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 [well, apparently by "traditional" DVD+RW vendors and not "latest generation" vendors such as Sony, NEC, TDK...] and a secret vendor-specific command manipulating this "Book Type" field was implemented. So if you fail to mount/play DVD+RW media, you might have an option to

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

    Once again. Not all vendors support this and you can't expect this utility to work with all recorders.

    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 might be possible to control how it [lead-in] is going to be branded by programming the drive in advance:

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

    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 "Compatibility Bitsettings" article at

    There [potentially] are other logical DVD+RW(*) format incompatibilities, 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 apparently never will be] by DVD Forum(**).

    (*) Finalized DVD+R media branded with DVD-ROM "Book Type" is virtually identical to DVD-ROM.
    (**) 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.

    Finally there is a physical incompatibility issue. They claim that there are 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...

    Technical Ramblings

    As for multisession ISO9660 [DVD] recordings! Unfortunately, Linux ISOFS implementation had certain deficiency which limits interoperability of such recordings. In order to understand it, have a look at sample ISO9660 layout to the right... Now, the problem is that isofs i-nodes(*) are 32 bits wide (on a 32-bit Linux) and represent offsets of corresponding directory entries (light-greens), byte offsets from the beginning of media. This means that no directory (green areas) may cross 4GB boundary without being effectively corrupted:-( It should be noted that in reality it's a bit better than it looks on the picture, as mkisofs collects all the directories in the beginning of any particular session (there normally are no blues between greens). The first session is therefore never subject to i-node wrap-around, but not the subsequent ones! Once again, files themselves may reside beyond the 4GB boundary, but not the directories, in particular not in further sessions. Having noted that directory entries are actually specified to start at even offsets, I figured that it's perfectly possible to "stretch" the limit to 8GB. But in order to assure maximum interoperability, you should not let any session start past 4GB minus space required for directory structures, e.g. if the last session is to fill the media up, it has to be >400MB. As of version 5.3 growisofs refuses to append a new session beyond 4GB-40MB limit(**), where 40MB is pretty much arbitrary chosen large value, large for directory catalogs that is. Yet it doesn't actually guarantee that you can't suffer from i-node wrap-around. Interim fs/isofs 2.4 kernel patch was addressed to those who have actually ran into the problem and have to salvage the data. Even though permanent solution for this problem appears in Linux kernel 2.6.8 (thanks to Paul Serice effort), growisofs keeps checking for this 4GB limit in order to ensure broader compatibility of final DVD recordings. This check is not performed for Blu-ray Disc recordings, as probability that a member of such user community would run something elder than 2.6.9 is considered diminishingly low.

    (*) i-node is a number uniquely identifying a single file in a file system
    (**) well, as DVD+R Double Layer support was introduced in 5.20, -use-the-force-luke=4gms option was added to override this behaviour (naturally recommended for Linux kernel 2.6>=8 users and kernel developers only;-)

    Why media reload is performed after every recording with growisofs? Well, it's performed only if you didn't patch the kernel:-) But no, I do not insist on patching the kernel! All I'm saying is that in the lack of kernel support, media reload is performed for the following reasons. In order to optimize file access kernel maintains so called block cache, so that repetitive requests for same data are met directly from memory and don't result in multiple physical I/O. Now the catch is that block cache layer remains totally unaware of growisofs activities, growisofs bypasses the block cache. This means that block cache inevitably becomes out of sync, which in turn might appear to you as corrupted data. Media reload is performed when flushing the block cache is not an option, e.g. only privileged user is allowed to perform it. Second reason is to force kernel to readjust last addressable block in case it was changed as result of recording. This is done to preclude spurious "attempts to access beyond end of device."

    What does [kernel] "DVD+RW support" really 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)" MMC 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 file system read-only). This is what the patch is basically about: noting when/if media was written to and "finalizing" at unlock door.

    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 SEQUENCE 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.

    Unfortunately the above paragraph doesn't seem to apply to the 1st generation drives, Ricoh MP5120A and derivatives:-( "SYNCHRONIZE CACHE (35h)" doesn't seem to be sufficient and the unit keeps replying with "COMMAND SEQUENCE 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. Even 2nd gen unit were reported to exhibit similar [but not the same] behaviour under apparently extremely rare circumstances. At least I failed to reproduce the problem... The problem repo

    Posted via email from mrgadgets's posterous
    Find more from me @