-----BEGIN PGP SIGNED MESSAGE-----
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.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.5 (GNU/Linux)
iD8DBQFFeK5JS9HxQb37XmcRAu0yAJ9KcLROjneC2wE36dE+H+VO6fF8ewCfaVNC
4nUSKXc9nihqjvMhH1HwnXQ=
=pB5J
-----END PGP SIGNATURE-----
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
