
     _________________________________________________________________

                            [1]DVD+RW for Linux

                by <[2]appro@fy.chalmers.se>, February 2002
     _________________________________________________________________

   Q.
          What is it (not)?
   A.
          Maybe to your disappointment it is not about video. The scope
          of this page is computer storage applications, things like
          backup, archiving, data exchange... The downloadable files are
          an optional [3]kernel patch and a couple of user-land utilities
          dubbed as [4]dvd+rw-tools.
   Q.
          Kernel patch? What's wrong with [5]cdrecord/cdrtools?
   A.
          Nothing! Moreover, you actually need them (cdrtools). It's just
          that you can't use them to manage DVD+RW media itself. DVD+RW
          media has no notion of [multiple] sessions or packet writing,
          so cdrecord[-ProDVD] wouldn't really know what to do. But most
          important is that DVD+RW is a true random write access media
          and therefore is suitable for housing of arbitrary filesystem,
          e.g. ext2, vfat, ufs, etc. This qualifies DVD+RW support for
          kernel implementation. However! Support for arbitrary
          filesystem doesn't quite work yet (see Technical Ramblings
          below) and as [6]dvd+rw-tools no longer require kernel support
          the kernel patch is optional.
   Q.
          What are dvd+rw-tools for?
   A.
          To [7]format blank DVD+RW media to start with. Secondly, even
          though you can put for example an ext2 filesystem on DVD+RW
          (theortically at the moment of this writing), it's not very
          practical because you most likely want to access the data on
          arbitrary computer. Or in other words you want isofs. Trouble
          is that you very likely want to add data now and then. And what
          options do you have in the lack of multiple sessions? Complete
          remastering which takes more and more time as dataset grows?
          Well, yes, unless you employ [8]growisofs! Even if you don't
          plan to add data, growisofs provides the way to burn the first
          "session" without kernel support.
   Q.
          [grow]isofs? Isn't udf the one to use?
   A.
          I don't mean to discourage you, but my personal experience with
          udf is rather poor. I couldn't mount an udf volume created
          under Windows in either Linux or Solaris... Your milage may of
          course vary and you are by all means welcome to prove me
          wrong:-)
   Q.
          What do I need [9]cdrtools for?
   A.
          The DVD+RW drives available on the market can burn even CD-R[W]
          media and cdrecord is the tool for this job. Besides, growisofs
          is nothing else but a front-end to mkisofs.
     _________________________________________________________________

  Foreword/Disclaimer

   Provided the absolute lack of support (or even formal encouragement
   for that matter) from vendor(s) you should consider this page to be a
   result of guesswork. There still is a couple of fatal failures
   indicated by vendor-specific error codes (see Technical Ramblings) and
   I didn't yet figured out the way around 'em. So the status of this
   "project" is rather "gathering experience" than "ready for production
   environment."
     _________________________________________________________________

  Tutorial

     * Upgrade your firmware (see [10]Ricoh, [11]HP, [12]MET pages).
       Fixed bug descriptions are vague, but at the very least after
       upgrade to 1.34 I could no longer reproduce infrequent "random
       positioning errors" when reading a file system with a lot of small
       files. 1.34 adds support for Verbatim media and 1.37 apparently
       for Memorex. Version 1.37 also implements a secret vendor-specific
       command which reportedly improves compatibility with a number of
       DVD-ROM drives (more about this matter in Technical Ramblings).
     * Make sure your DVD+RW drive is "routed" 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=hdX
pre-install sg modprobe ide-scsi
pre-install sr_mod modprobe ide-scsi
pre-install ide-scsi modprobe ide-cd

     * Formatting the media. Just pass the device name as an argument to
       [13]dvd+rw-format (needless to say, you have to compile it first).
       To make formatting process reasonably fast the media gets
       formatted only partially. If you run dvd+rw-format against newly
       formatted media, you'll see something like this:

* DVD+RW format utility by <appro@fy.chalmers.se>, version 2.0.
* 4.7GB DVD+RW media detected.
- media is already formatted, lead-out is currently at
  442368 KB which is 9.6% of total capacity.
- you have the option to rerun with -f flag to enforce
  new format (not recommended).

       "9.6% of total capacity" doesn't mean that you can only write that
       little. The unit will transparently move the lead-out as you add
       more data. If you don't beleive me, execute 'dd if=/dev/zero
       of=/dev/scdN bs=32k seek=143443 count=1' (kernel support is
       required for all dd commands on this page!) and rerun
       dvd+rw-format. Keep in mind that 4.7GB are salesman's GB, i.e.
       1000^3 and not 1024^3.
       Reformatting (with version 2.x) is more or less meaningless and
       therefore not recommended. Former recommendtations for
       reformatting were for privacy reasons. This is no longer the case
       because so called "immediate" command form (utilized in version
       2.x) doesn't attempt to zero all the data written so far. If you
       are concerned about privacy, nullify explicitely with 'dd
       if=/dev/zero of=/dev/scdN bs=32k'. Kernel-support-less alternative
       is to create few huge empty files(*) and 'growisofs -Z /dev/scdN
       huge*.void'.
        (*)
               The most gracious way is probably to 'touch huge1.void
               huge2.void huge3.void' and then to 'perl -e 'truncate
               ("hugeN.void", 0x7ffffffe)'' corresponding number of
               times. Yes, it gives you 6GB in total and growisofs shall
               fail with volume overflow, but it doesn't matter as by
               that time the disc will be nullified already.
     * Using [14]growisofs. There is no manual for growisofs as there is
       very little need for one. In a nutshell growisofs just passes all
       command line arguments to mkisofs and dumps its output directly
       onto the media. The first part means that you basically can [well,
       should] consult [15]mkisofs manual page and accompanying reference
       documention (including multisession related section[s]) and the
       second part means that you shouldn't expect an ISO-image on the
       standard output (nor make sure you have enough free space on the
       disk). Differences from mkisofs 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 "burning,"
            this implements formerly 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 -R -J -Z /dev/scd0 /some/files
growisofs -R -J -M /dev/scd0 /other/files

       Oh! Do make sure you have at least mkisofs 1.14 on your $PATH
       (mkisofs 1.14 is part of cdrtools 1.10).
     * Patching the kernel is optional. [16]Download the kernel patch,
       apply it, recompile kernel and re-install (cdrom.o and sr_mod.o
       modules), but don't ask me [17]how. 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". At this point you should be able to 'mke2fs -b 2048
       /dev/scdN' (theoretically at the moment of this writing) or
       'mkisofs -pad . | dd of=/dev/scdN obs=32k' and observe kernel
       logging "srN: dirty DVD+RW media." And once again! Even though it
       should be possible to lay arbitrary file system down on DVD+RW
       media, it is not quite working yet:-( Updated kernel patch
       addressing this issue is being worked on. As for the moment of
       this writing growisofs is the only working option.
     * Performance optimizations. 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 won't work as /dev/raw expects
       specifically aligned buffer... Good news are that [18]sdd aligns
       the transfer buffer so that if you've got an image to burn down
       (or want to nullify) stick to 'sdd of=/dev/raw/rawX obs=32k ...'
     _________________________________________________________________

  Technical Ramblings

   What does "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 filesystem read-only). This is what the
   patch is basically about: noting when/if media was written to and
   "finalizing" at unlock door...

   As already mentioned arbitrary file system doesn't quite work:-( It
   turned out that the unit (at least [19]hp dvd100i) sometimes (most
   notably after bulk writes) requires "FLUSH CACHE (35h)" command for
   normal operation. It apparently asks for it by returning "COMMAND
   SEQUENSE ERROR (2Ch)" ASC. So the idea for implementation is to inject
   "FLUSH CACHE" commands whenever the unit signals this ASC...

   This one beats me. Sometimes the unit simply stops writing signalling
   a vendor specific positioning error, 03h/15h/82h to be specific.
   Especially if the media is newly formatted. Couple of work theories.
   One is that block buffer cache reorders requests so that they are not
   sequential anymore, "FLUSH CACHE" might do the trick. Another one is
   that under "underrun" condition background formatting kicks off and
   has to be explicitely stopped. "Underrun" is in quotes because the
   unit is supposed to handle temporary data stream outages gracefully.
   If you run into this (you most likely will), try to complement
   growisofs command line with [undocumented] -poor-man option. This
   option eliminates request reorders and minimizes possibility for
   "underrun" condition (by releasing the pressure off VM subsystem).

   The original idea was to implement DVD+RW support in
   drivers/cdrom/cdrom.c. Unfortunately SCSI layer maintains private
   "writeable" flag controlling the ability to issue WRITE commands. The
   flag is impossible to reach for from the Unified CD-ROM driver. But
   why am I talking about SCSI when there are only IDE units out there
   (at least for the time being)? Well, as you most likely want to
   occasionally burn even CD-R[W] with cdrecord you want it to go through
   ide-scsi emulation layer anyway. So I figured that SCSI CD-ROM driver
   is the one to aim for even for DVD+RW.

   Unfortunately it was not possible to implement it completely in
   sr_mod.o:-( Minor drivers/cdrom/cdrom.c modification was required to
   sense the media before decision about whether or not to permit write
   open. That's because DVD+RW drives (well, I can speak for [20]hp
   dvd100i only, but I bet the others are similar) are morphing their
   behaviour after currently mounted media and it's essential to identify
   newly inserted media.

   Special comment about "what a dirty hack!!!" To my great surprise it
   turned out that timeout value you pass in cdrom_generic_command is
   simply ignored and timeout is set to precompiled value of 30 seconds.
   Unfortunately it's way too low for formatting purposes and I had to do
   something about it. Alternative to "the dirty hack" was to add another
   argument to sr_do_ioct and modify all the calls to it... I've chosen
   to take over those 31 unused bits from the "quiet" argument instead of
   modifying all the calls (too boring).

   There is another kernel "deficiency" I ran into while working on the
   (original version of) dvd+rw-format utility. The drive provides
   background formatting progress status, but unfortunately it's
   impossible to access it. That's because progress counter is returned
   [in reply to "TEST UNIT READY"] as "NO SENSE/LOGICAL UNIT NOT
   READY/FORMAT IN PROGRESS" sense bytes but with "GOOD" status.
   Apparently any sense data with "GOOD" status is discarded by the
   common SCSI layer.

   It was pointed out to me that DVD+RW units work with Acard [21]SCSI to
   IDE bridges.
   ___________________________________

  ... and a request for [vendor] comment

   Probably the only DVD+RW's deficiency is the [22]incompatibility list.
   The question I so far failed to find definite answer to is "what is
   actually limiting the compatibility?" Is it the optical
   characteristics of DVD+RW media alone (meaning that those who has
   incompatible drives are basically screwed unless DVD+RW media vendors
   come up with better media)? Or is it something else (which leaves the
   window of opportunity open)? Clearly I'm not in a position to figure
   it out by myself. Unfortunately what I feel at this point is that
   vendors (both DVD+RW and DVD-ROM) could be less ignorant and do more
   than just pointing at their sales departments. I asked the above, but
   got basically nowhere, see the transcript below...

   However! Here is an observation. The FAQ claims that "DVD+RW is
   designed from the start to be compatible with existing DVD-ROM drives
   and DVD-Video players, both on a physical as well as a logical level."
   After examining the MMC-3 draft, "[DVD] Sector Configuration" section
   (see [23]T10 site) I can't quite understand how compatibility at
   logical level is provided. In particular how the Data Type bit present
   in every sector and defined as following:

         Media Type                 Data Type bit
                            0                       1
            ROM       Read-only data               N/A
            RAM       Embossed data          Rewritable data
             R        Read-only data   Next sector is Linking Data
            -RW     Re-Recordable data Next sector is Linking Data
            +RW            N/A               Rewritable Data

   is [supposed to be] interpreted? To me zero for "Rewritable Data" in
   the last line would actually make more sense. Indeed, if a "pure"
   DVD-ROM drive was to interpret the bit as it is now, it would have to
   interpret all sectors on DVD+RW media as non-data and would fail to
   mount the media. Obviously "pure" DVD-ROM drives ignore the bit and
   the remaining question is then "what do DVD-R[W] capable drives (like
   the vast majority on the [24]incompatibility list) do?" Especially if
   we imagine that they mistakenly recognize DVD+RW media as DVD-R[W] (by
   misinterpreting or ignoring the "Book Type Field" burned in Control
   Data Zone)? Shall they interpret the bit as "Next sector is Linking
   Data?" But that is definitely not what DVD+RW unit has written there,
   which should most likely prevent the drive from mounting the media...
   If there is anybody out there who can clarify this, drop me a line.

  ... am I on the right track?

   As already mentioned firmware version 1.37 implements a secret
   vendor-specific command which reportedly improves compatibility with a
   number of DVD-ROM drives. Though not all:-( But do you want to know
   what it does anyway? In the lead-in area there is so called Layer
   Descriptor. You can access it with "READ DVD STRUCTURE (ADh)" command.
   First byte of this descriptor identifies "book" compliance (see MMC
   specifications). The secret command permits you to change this "Book
   Type Field" (as well as "Part Version") to whatever you like. Well, HP
   utility dubbed [25]DVDBitSet.exe lets you to choose between 92h
   (DVD+RW book version 2) and 01h (DVD-ROM book version 1), but under
   the hood you can pick any number. The command has two variants, namely
   drive settings affecting disks to be written and media setting
   affecting the disk currently in the drive. So does it mean that
   compatibility with DVD-ROM drives is about logical format? If yes,
   then what's next? More fields in Layer Descriptor, e.g. "Maximum Rate"
   and "Layer Type?" "Media Type" bit?

  ... yet another observation.

   [26]Users at dvdplus.org have reported that Toshiba SD-C2402 sometimes
   manages to mount DVD+RW media with DVD-ROM value in "Book Type Field"
   (see above). I myself have SD-C2302 and got very excited by this news.
   I found that my drive also sometimes manages to mount such media and
   that it seems to depend on initial angle!? I mean I could [instantly]
   mount and play the disc several times in a row having it oriented in a
   certain manner before I push the tray in... But what happens
   otherwise? You hear the disc spinning up, then you hear "br-r-r-r,"
   spinning up, "br-r-r-r" and so on, till it gives up... Take the disc
   out and turn it over. You'll see about 1-1.5mm inner ring of same
   colour as virgin rewritable surface. Outer edge of this ring is where
   the lead-in starts, right? Now, if you compare different DVD+RW discs
   you'll very likely notice that the start position of lead-in is
   different. I've observed the radius vary from somewhat smaller than
   23mm to ~23.5mm. Why does it vary? Does this violate standard?
   Standard only specifies the position of first user-accessible logical
   block (LBA 0) which is expected to be found around 24mm. It does not
   specify how long the lead-in should be. But if the unit burns lead-ins
   of the same length, does it mean that LBA 0 gets burned by DVD+RW unit
   with at least 0.5mm radial variation? 0.5mm is quite a lot (~38MB) and
   I reckon that it takes longer to play it than it takes for my drive to
   fail and retry, meaning that 0.5mm should matter. Finally! Whenever
   the drive succeeds to mount the media it provides perfect playback,
   i.e. no retries or bad sectors were observed. The latter makes me
   conclude that DVD+RW reflectivity is hardly the limiting factor...
     _________________________________________________________________

    Partial vendor communication transcipts

   I I'm looking for a DVD+RW capable notebook DVD drive.
   Toshiba The only drive that supports new DVD rewrite disks is a new
   drive, the SD-M1612.
   I ??? SD-M1612 is a) not the only DVD+RW capable Toshiba drive, b) is
   a DVD-RAM drive, c) is not a notebook drive... Can you at least tell
   if your latest SD-C2502 notebook drive can mount DVD+RW media?
   Toshiba It could be that it can read it as the format is similar to
   DVDR, but as a rule Toshiba does not support and does not mention this
   format as supported media for its drives.
   I DVD+RW is similar to DVD-ROM, not DVD-R or any other format.
   Toshiba As long as DVD+RW is not recognised as a official format by
   the DVD forum Toshiba will NOT support this format.
     _________________________________________________________________

   I Does HP have any comment on this statement?
   HP The Toshiba players SD-2705, SD-M1212, SD-M1402, SD-M1502 players
   have been tested to be fully compatible with the DVD+RW format. HP is
   not responsible for the comments of other manufacturers.
   I Can you at least recommend a notebook drive?
   HP You will have to contact a local HP reseller to resolve the issue.
     _________________________________________________________________

   I Does Philips have any comment on Toshiba's statement?
   Philips A well designed DVD-Video/ROM drive will be able to play-back
   DVD+RW/R discs without problems. If not, there is either a mistake
   (should be improved by that player manufacturer) or intentionally
   blocking play-back. In that case customers should be warned for the
   limited functionality of that drive. Of course customers will also
   complain by that player manufacturer (in this case Toshiba) because
   all competitor drives can play those discs and they can not. People
   will not like that kind of attitude.

   Beside Toshiba notebooks Toshiba drives can be found in HP(!), IBM,
   Dell, Compaq, Sony, Fujitsu/Siemens notebooks... And guess what, the
   latest SD-C2502 drive fails to mount DVD+RW media...

References

   1. http://www.dvdplusrw.org/
   2. mailto:appro@fy.chalmers.se
   3. http://fy.chalmers.se/~appro/linux/DVD+RW/linux-2.4.patch
   4. http://fy.chalmers.se/~appro/linux/DVD+RW/tools/
   5. http://www.fokus.gmd.de/research/cc/glone/employees/joerg.schilling/private/cdrecord.html
   6. http://fy.chalmers.se/~appro/linux/DVD+RW/tools/
   7. http://fy.chalmers.se/~appro/linux/DVD+RW/tools/dvd+rw-format.c
   8. http://fy.chalmers.se/~appro/linux/DVD+RW/tools/growisofs.c
   9. http://www.fokus.gmd.de/research/cc/glone/employees/joerg.schilling/private/cdrecord.html
  10. http://ext.ricoh.co.jp/dvd/asia/support/download/mp5120a/
  11. http://www.hp.com/cposupport/information_storage/software/dvd100i_137.exe.html
  12. http://www.met.com.tw/eng/support/download/cdrw/oem/rw5120a.htm
  13. http://fy.chalmers.se/~appro/linux/DVD+RW/tools/dvd+rw-format.c
  14. http://fy.chalmers.se/~appro/linux/DVD+RW/tools/growisofs.c
  15. http://www.fokus.gmd.de/research/cc/glone/employees/joerg.schilling/private/man/mkisofs-1.14.html
  16. http://fy.chalmers.se/~appro/linux/DVD+RW/linux-2.4.patch
  17. http://www.linuxhq.com/patch-howto.html
  18. ftp://ftp.fokus.gmd.de/pub/unix/sdd/
  19. http://dvd.hp-at-home.com/
  20. http://dvd.hp-at-home.com/
  21. http://www.acard.com/eng/product/scside.html
  22. http://www.dvdplusrw.org/resources/compatibilitylist_dvdrom.html
  23. http://www.t10.org/scsi-3.htm
  24. http://www.dvdplusrw.org/resources/compatibilitylist_dvdrom.html
  25. http://www.hp.com/cposupport/information_storage/software/dvdbitset.exe.html
  26. http://www.dvdplusrw.org/cgi/ikonboard/forums.cgi?forum=2
