Re: Making UDF DVD+RW backups
> Therefore, I use the following procedure (with Andy Polyakov?s patch applied)
You don't need the patch for that. What you're doing is creating the
filesystem in a loop-mounted file, then burning that file as disk image.
Whether you start with an empty file or with a disk image read from an
existing disk is irrelevant. Btw the truncate function of the C-library
is very handy for creating humangous empty files. Also, you can use any
filesystem you like, except iso9960 because that can't be mounted
readwrite.
Unfortunately, this is the only method with actually works on Linux.
Andy's kernel patch is brilliant, if you only want to make small
modifications it's very good. For larger changes (certainly when many
files are involved), random access writing on Linux is a non-event from
a practicality point of view.
Btw the udf filesystem itself is buggy too when writing - about 10% of
my symlinks get chopped and point to the empty string. This can be fixed
by another run of rsync.
I did some qad speed tests on ext2 and udf, and found that with both,
depending on read operations, the whole thing can grind itself to a
halt. Neither was outstandingly better than the other for DVDs/CDs.
However, ext2 has other significant advantages: 100% bug free, e2fsck,
resize2fs, useful documentation. When I had to start a scratch a third
time because the udf filesystem I created was yet again a few MB too
small I decided to udf = RIP. This was helped by the fact that there is
no information on how to use the options of mkudffs in google, nor was
that question of mine answered by anyone on this list. Ext2 uses less
space for itself than udf if you reduce the number of inodes to
something approaching what is actually used.
You also might want to consider copying files into the filesystem in
alphabetical order, it'll speed up reading in some cases. I do this by
creating an empty filesystem (loop mount) and copying the files into
it, umount, and burn. This should also defragment ext2 a bit. There's a
script (yes, correct - there is no single command which can actually do
this, and you have to do it as root) called cp-sort in the scriptutils
package on my website (it also contains a wrapper-script to the
truncate system function).
Using growisofs -M is an alternative (which I haven't tried myself but
expect to work). As you observe, mkisofs -udf doesn't yet cut it. That
leaves mkisofs with iso9660 - a fine solution, *unless* you want to
store hardlinks. To be precise, you can *store* them, just not read
them. This is a bug in the Linux iso9660 for which there is no general
solution available, and won't be either. The only hope here is someone
making another mount option and mod to the iso9660 which can handle
hardlinks, at the expense of a small risk that some Microshite CDs
won't read any more properly with this thing turned on.
The packet writing driver fares much worse. I can copy a CD image to
disk, make changes, and burn it back in less than 10 minutes. Writing
400MB (I think) onto a cd-rw with the packet driver takes 45 minutes.
Not mentioning the kernel panics and the corrupted files on the CD,
it's maybe something for kernel 2.8. Linux is trailing M$ by a large
number of years by then.
Volker
--
Volker Kuhlmann is possibly list0570 with the domain in header
http://volker.dnsalias.net/ Please do not CC list postings to me.
Reply to: