Using DVD+RW discs

23 January 2007

After more frustrations with getting sensible write speed from DVD-RAM, I decided to dig out some DVD+RW discs I bought a while back and see what the speed was like writing to them.

Firstly, there were several baroque commands to be overcome, just to write anything to the disc. This seemed to be the magic formula:

dvd+rw-format -f /dev/hdd
pktsetup dvdrw /dev/hdd
mkudffs --media-type=dvd /dev/pktcdvd/dvdrw
mount -t udf /dev/pktcdvd/dvdrw /mnt/dvdrw
mkdir /mnt/dvdrw/backup
cp a_large_file /mnt/dvdrw/backup
umount /mnt/dvdrw/backup

The fall and rise

22 August 2006

Today I discovered Reggie Online. Absolutely priceless.

Fixing DVD-RAM write performance on Linux

20 July 2006

For a while I've had a LG GSA-4167 DVD recorder in my PC. Whilst I'd been able to cut DVD-R discs quite successfully, I'd never been able to get anything approaching acceptable write performance out of the drive when using DVD-RAM discs, especially when using them for backups. Although it would sometimes achieve the expected 2MB/s, most of the time it would be apparently doing nothing, or writing a few tens of kB/s. Also, the head appeared to be frequently stepping around a lot.

I did notice that suspending the backup process with Ctrl-Z before the number of dirty blocks got too high, then running sync, seemed to drain the blocks to the disc much faster.

I finally decided to do some digging. Eventually I found various pages. One example is on gmane. It turns out that although DVD-RAM is advertised as having random-access 2kB sectors, the ECC scheme used on the disc requires 32kB (16 sectors) to be written as a whole.

So why the slowdown when the page cache gets full of dirty pages destined for the DVD-RAM drive? I suspect that normally (or if sync is run), the OS drains the pages to the disc more or less in order, allowing the drive to batch them into 16 sector groups within its cache. However, once the OS is under memory pressure, it starts writing pages in a more random fashion, exposing a bad access pattern for the drive requiring lots of read-modify-write passes.

This was borne out by doing

dd if=/dev/zero of=/dev/hdd obs=32k

which wrote at 2MB/s until the page cache filled, at which point the bad behaviour kicked in again.

At that point, the realisation dawned that I needed to force the block size to be 32kB. I vaguely remembered something about packet CD, which I'd tried once to do random access to CD-RW. (That experiment didn't last long, because the performance sucked even more than the DVD-RAM.) In fact, I still had the packet CD driver compiled into my kernel. However, I didn't have a working version of the user-land tools because when I tried to do

pktsetup ram /dev/hdd

I was greeted with a complaint about inappropriate ioctl for device. (This was pktsetup from a locally built copy of the vanilla udftools from SourceForge. A bit of googling later and I turned up that this patch was required to fix the problem I had. In fact, I had to hack the sources again myself; here was my patch.

--- udf_vanilla/udftools-1.0.0b3/wrudf/wrudf.c  2002-11-26 07:18:51.000000000 +0000
+++ udftools-1.0.0b3/wrudf/wrudf.c      2006-07-19 22:08:51.000000000 +0100
@@ -245,7 +245,10 @@
            } else if( strncmp( spm->partIdent.ident, UDF_ID_VIRTUAL, strlen(UDF_ID_VIRTUAL)) == 0 )
                virtualPartitionNum = i;
        }
+  spm = (struct sparablePartitionMap *)((char *)spm + spm->partitionMapLength);
+#if 0
        (char*)spm += spm->partitionMapLength;
+#endif
     }
 
     if( medium == CDR ) {

Once this was all done, I could proceed with the build

CC=gcc CFLAGS=-O2 ./configure --prefix=/other/udftools/1.0.0b3-telia-1
make
(as root) make install
(as root) spill /other/udftools/1.0.0b3-telia-1 /usr/local

Now I could run pktsetup successfully. At this point, the next issue was what filesystem to use, and whether to just rsync the files to the disc, or whether to use dar to gather the files into a backup image.

After a bit of experimentation I found

Using rsync to write onto ext2 was on the whole pretty fast, but there were occasional periods with very low write speeds and head seeking. Formatting the disc in the first place took many minutes - almost too slow to be tolerable in itself.
Using rsync to write onto udf was similar, except that there were even worse periods of low write speed and even more head seeking. These started to get so long that I began to fear for the health of the drive, and cut the job short.
Using dar to write onto ext2 was definitely faster than rsyncing the individual files. I guess there is less metadata to update, because only 1 inode is involved. However, even this succumbed to lots of head seeking when the disc reached about 3GB full.
Using dar to write onto udf seemed to be the winner. However, by this point I wasn't watching closely so I'm only going by the time taken.

The final outcome was that I could achieve an average write speed of about 1.7MB/s, i.e. 1GB in about 10 minutes. This was onto a 2x-3x Panasonic DVD-RAM disc. The winning formula was:

pktsetup ram /dev/hdd
mkudffs --media-type=dvdram /dev/pktcdvd/ram
mount -t udf /dev/pktcdvd/ram /mnt/ram
cd foobar
dar -c /mnt/ram/foobar

I imagine that doing a tar onto the bare device would win hands-down, because it wouldn't require seeking around the disc to write block bitmaps and other metadata. However, it would be the least practical for data retrieval or for writing other data to the disc later.