Re: [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