[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Dvdrtools-users] 2GB file limit workaround
From: |
Bryan J. Smith |
Subject: |
Re: [Dvdrtools-users] 2GB file limit workaround |
Date: |
Fri, 13 Jun 2003 23:02:07 -0400 (EDT) |
User-agent: |
IMP/PHP IMAP webmail program 2.2.7 |
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