Re: backup archive format saved to disk
Douglas Tutty wrote:
On Tue, Dec 05, 2006 at 06:57:38PM -0600, Ron Johnson wrote:
>
You could implement your own FEC. A very simple form of FEC is simply
Yes, but *why*? Tape storage systems have been using ECC for decades.
There's a whole lot of "Linux people" who's knowledge of computer
history seems to have started in 1991, and thus all the many lessons
learned in 30 years of computing are lost.
Hi Ron,
I'm hoping someone who can remember computer history prior to 1991 can
give some perspective.
It think (__please__ correct me if I'm wrong) that the tape systems had
the ECC as part of the hardware. Write a plain datastream to the drive
and the drive did the ECC part transparent to the user. Read the data
and a bad block gets fixed by the hardware ECC.
The 9 track tape drives had two forms of EDAC. One was the fact that
each byte was written with a 9th check bit, even parity IIRC, allowing
some detection, and some FEC on a block basis, IIRC.
I'm told that modern hard drives also do ECC but I can't find out how
that is implemented. I'm told that if a block starts to fail (whatever
that means) then the data is transferred to a new unallocated block,
transparent to the rest of the computer. Only if the drive runs out of
unallocated blocks does it give errors.
That's the way fixe discs work, usually with 11 bit BCH code, and also
the way DAT works. Whatever other tapes may be in use, I don't know what
they do. CDs also use some FEC (two Read-Solomon codes, one for
thumbprint correction, and one for long-burst errors), but I don't know
whether they do that when using a data format, as opposed to music.
The question is, if a block is sucessfully written now, if the drive is
not used for 5 years then a read is attempted, is the drive able to
retreive that data using ECC (as a tape drive could)?
I thought the question was "How can I be sure I can get my data back?"
So far, some people have suggested few techniques to accomplish that,
but all I've seen is complaints in response.
I guess I don't know what the question is.
Since I don't __know__ that it can, I'm assuming that it can't. I'm
playing my own devils advocate and trying to find out how to plan to be
able to read successfully off a drive with bad blocks after years of
sitting on a shelf.
IF this is what your goal is, then, as I pointed out, you can implement
your own FEC.
I'm focusing on the one-drive issue because this is one drive sitting in
a bank vault. This is __archive__ (just like tape). I have backup
procedures as a separate issue. One of the places that backup data goes
to is the bank vault archive.
If the issue is a drive, then you need more than one drive. If the
drive itself fails, then you are SOL.
In the absence of an all-in-one archive format, I'll use tar (which can
detect errors just not fix them) to take care of names, owners,
permissions, etc. Then that tar needs to be made ECC and compressed.
If I want to throw in a monkey, I'll consider encryption.
Yes tape drives do that. Its probably why they cost so much. Hard
drives are much cheaper and are supposed to be able to hang on to their
data (Seagate gives a 5 year warranty). But having seagate give me a
new drive when I can't get my data off after 4 years is cold comfort.
Hard disc drives use FEC (usually a BCH 11 bit redundant code).
If you want to be able to read more reliably than the FEC already
present, you'll have to add your own.
The other problem with tapes is their fragility. Drop a DLT and I'm
told that its toast. Put that tape in the drive and I'm told it can
The most common cause of that is edge damage.
damage the drive. A laptop drive in a ruggedized enclosure is much more
robust and has a wider environmental range.
Perhaps what I'm looking for doesn't exist. If it doesn't, I'll start
work on it.
Hmm. You going to become an expert at designing ECC? I suggest you take
a course in abstract algebra first.
As far as computer history prior to 1991, I could never get the hang of
C. I'll stick with fortran77.
Which progamming language one uses is less important than the algorithm
implemented.
Mike
--
p="p=%c%s%c;main(){printf(p,34,p,34);}";main(){printf(p,34,p,34);}
This message made from 100% recycled bits.
You have found the bank of Larn.
I can explain it for you, but I can't understand it for you.
I speak only for myself, and I am unanimous in that!
Reply to: