[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[Dvdrtools-users] 2GB file limit workaround
From: |
Bryan J. Smith |
Subject: |
[Dvdrtools-users] 2GB file limit workaround |
Date: |
14 Jun 2003 01:51:49 -0400 |
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