On Tue, Dec 05, 2006 at 07:55:40PM -0600, Mike McCarty wrote: > Douglas Tutty wrote: > >On Tue, Dec 05, 2006 at 06:57:38PM -0600, Ron Johnson wrote: > > > > > > >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'm not complaining Mike. Also, note who's saying what; there's a few voices in this conversation. Please don't take my questions the wrong way. I am very gratefull for the wisdom. I'm just trying to tease apart where failures can occur and what can mitigate them. > > 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. > Yes I could. The origional question was to see if one existed already. > >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. > So drive failures are atomic? I.e. if in 5 years I go to read a drive and it has errors, everything is toast? I'm wanting a data-stream format (call it a file system, an archive format, whatever) that can withstand those errors. > >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. > Can (or at least I used to be able to) do the algebra, but that's not the issue. There are programs like par2 that do the ECC stuff but put it in separate files. If I went that route, I just have to pack it all together. > >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. > True. Thanks. Doug. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
