[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: backup archive format saved to disk

Hash: SHA1

On 12/07/06 17:36, Mike McCarty wrote:
> Ron Johnson wrote:
>>> Ron Johnson wrote:
>>>> RAID is *not* for archives!!!
>>> RAID was not designed for archives. I can see no reason why
>>> it wouldn't work for that. RAID 1, for example, is simply
>>> making two (or more) copies of the data. Are you saying that
>>> making more than one copy of a backup is not a reasonable
>>> approach?
>> [snip]
> [I wrote]
>>> The main advantages would be that one would essentially
>>> have burst error correction of the size of the disc
>>> (this being, with the FEC on the disc, if any, an
>>> interleaved code in effect), which is enormous, indeed,
>>> and economy in storage over using multiple copies, as
>>> illustrated above.
>> I'd only trust "RAID archiving" if the controller and a rescue CD
>> were also stored in the "archive location" along with the hard drives.
> I gave two examples of RAID archiving which required no
> special controller, and which would need to special rescue CD
> to use. You snipped those, and didn't answer my question.
> I'll ask the question again, and then I'll supply you with
> a simple software RAID implementation which I wrote in
> less than 15 minutes.
> RAID level 1 is simply multiple copies. Do you think that
> making multiple copies of the backup is an unreasonable
> way to protect data from loss?
> One way of doing RAID 5 with three discs is to write data
> to each of two discs, and write the bitwise XOR of the
> data on the two discs to a third. This requires no special
> controller, it simply requires a tiny program. Here's one
> in completely portable C:

Separate parity disk is RAID-4, not -5.

> #include <stdlib.h>
> #include <stdio.h>
> int     main(void) {
>     FILE    *Input1, *Input2, *Output;
>     int     Chr1, Chr2;
>     Input1 = fopen("disc1.raw","rb");
>     Input2 = fopen("disc2.raw","rb");
>     Output = fopen("disc3.raw","wb");
>     if (!Input1 || !Input2 || !Output)
>         fprintf(stderr,"unable to open files\n"), exit(EXIT_FAILURE);
>     while ((Chr1 = fgetc(Input1)) != EOF && (Chr2 = fgetc(Input2)) != EOF)
>         fputc(Chr1 ^ Chr2,Output);
>     if (Chr1 != Chr2) {
>         if (Chr1 == EOF)
>             Input1 = Input2;
>         while ((Chr1 = fgetc(Input1)) != EOF)
>             fputc(Chr1,Output);
>     }
>     return EXIT_SUCCESS;
> }

Shouldn't these be raw devices instead of files on filesystems?

> Code compiled but not tested. The files disc1.raw and disc2.raw
> are the inputs, disc3.raw gets written. This program works both
> to create the image, and to recover from a fault in one of the
> discs. The shorter disc image is padded with bytes with all bits
> off to fit the length of the longer. For recovery this would
> need some change, of course, to truncate the output as necessary.
> This program has, of course, no error checking or other fancies.
> It is a proof-of-concept prototype only. But it shows just how
> simple a RAID system can be.

What you've done is create a parity disk.  Useful, but not RAID.

- --
Ron Johnson, Jr.
Jefferson LA  USA

Is "common sense" really valid?
For example, it is "common sense" to white-power racists that
whites are superior to blacks, and that those with brown skins
are mud people.
However, that "common sense" is obviously wrong.
Version: GnuPG v1.4.5 (GNU/Linux)


Reply to: