Hi, r.basak!
Trying to kill the keyboard, [EMAIL PROTECTED]
([EMAIL PROTECTED]) produced 1,4K in 51 lines:
> On Fri, Jul 28, 2000 at 11:05:54AM +0200, Wolfgang Weisselberg wrote:
> > Remember though that a single bit error can (and probably[1]
> > will) kill all of the backup after the error.
> Yes. I don't know about other drives, but the Ditto Max uses ECC, so
> isn't this unlikely?
EVERY tape device uses ECC, so do HDs[a]. So does good memory,
and your L2 cache probably has ECC, too. TCP/IP has no ECC,
but checksums and resending of packages.
Tapes *have* to use ECC, because errors do happen. 'A lot'
of times. Ftape tells you about rereads and soft/correctable
ECC errors. Just look into your logfile. My old Ditto
3.2/1.6GB used to have one such error on every few 100MB,
on good days. But then it was a monday machine.
> A failure with the ECC on the tape is just as
> likely as a failure of ECC (or whatever other system you use) in [1],
> isn't it?
> > [1] There are ways to avoid it, but to do that safely and
> > usably, one would have to dive deep into cryptography.
There is NO ECC at all in cryptography. No redundancy.
None at all.
Redundancy in the output means bad crypto, thus once encrypted
you should be quite unable to compress the output[b]. Even if
your plain text was 100KB of 'a's. (Actually, pgp compresses
before encryption, both to save space and (de)compression
time and to remove most redundancies from the plain text,
making it even harder to crack.)
However, you should have ECC on whatever medium you save the
output stream from the compression ...
-Wolfgang
[a] As HDs today use PRML (Partial Response, Maximum
Likelyhood), which allows much denser tracks at the
expense of a crystal clear signal (you partly hear the
tracks next to you), you need advanced signal filtering
and ECC to be able to be sure you reconstructed the
correct data.
But that means you can start reading while the head still
stabilizes on the track. Worst case: you get bad data,
recognize it and wait for the platters to turn a complete
360�s to read that bit again. The rest or the track can
then be sent out of the tape's buffer.
Of course you cannot do that during writing data, but that
happens less often after all.
[b] If you can significantly compress it, something is very
wrong, there's a pattern in the output! Good output is
very hard to distinguish from 'white noise'.