[Dvdrtools-users] 2GB file limit workaround

[Bryan J. Smith]

Quoting Volker Kuhlmann <address@hidden>:
> Are you sure? Joliet is an optional extra, on unix it's just a waste
> of space.

Joliet extensions have various limitations on file paths and names.  I run
 into them regularly.  Not using Joliet fixes the issue (bare ISO9660 or
 ISO9660+RockRidge-only).

> Unless you have specific reason to have a tar format on disk, you
> could just skip making the tar file. If you're dealing with a file larger
> than a DVD, the raw method is to use split (and copious quantities of
> md5sum and disk space).

Remember, ISO9660 (and UDF) is an archiving format** on its own.  When you
 use another archiver, you "double archive" which results in increased
 recovery time to "unarchive."

[**NOTE:  This doesn't make sense until you realize the "imaging" operation
 is the "archiving" and the "recording" is the "extraction."  Then it makes
 total sense.  CD/DVD is an archive media that is random-access, unlike tape
 and other sequential methods ]

> Am I the only one who finds that Linux is now too crappy to read
> CDs/DVDs? Most of the time I get an error with that. Kernel 2.4.20.

Nope.  I've just had issues with my Matsushita LF-D310 (3G DVD-RAM) lately. 
 It's not even a year old.  A CD-RW and DVD-ROM drive in the same system has
 no issues.

> md5sum is twice as fast as cmp, as cmp needs to read both sets of
> data, md5sum only one. Compared with the time it takes only one set of
> data, the time of computing the md5 is insignificant.

I've done some benchmarks of 128-bit MD5 via md5sum and 16/32-bit CRC via
 checksum.  No difference in speed on modern x86 CPUs AFAICT.


--
Bryan J. Smith, E.I.  mailto:address@hidden  http://thebs.org