>Hans Franke wrote:
> > Jerome Fine wrote:
> > As for the RAID 1 (mirroring) function, don't wait until you have
> > a hard drive failure. Find some way to simulate an error - I just
> > unplugged one hard drive. If the RAID 1 firmware/software
> > can't handle the problem, then the mirroring function is not much
> > use when you don't know what the problem is. So if the RAID 1
> > is not helpful after you have the problem and if you never have
> > a problem you don't need RAID 1 in the first place, why bother.
> Well, that's what I exectly started to test. As I told earlyer,
> when plugging in a new disk it did duplicate the existing disk
> onto the new one right away. The above mentioned test was if both
> copies are independant usable as first drive for recovery.
Jerome Fine replies:
I find it extremely interesting that we both immediately thought
about the problem in the same manner - we both assumed that
the RAID 1 (mirroring) function MUST be verified via an
operational test BEFORE we would rely on it. NOW, that
says a great deal about the software industry in general.
If anyone else is following this thread, please comment on
what you perceive as your conclusions with respect to
the reliability of software in general and any application
that you have had difficulty with in particular.
> I won't start the final test, the one where I put both disks
> together again, to see how it recovers teh inconsistent system,
> until next week, since I need the machine to woork the next 3 days.
Which is another way of saying you can't trust the RAID 1
firmware before you test it. PLUS, these days most systems
are so reliable that backups are rarely used - even though they
are still ESSENTIAL since systems fail not only because of
hardware, but from my experience more often due to faulty
software.
> > EXCEPT in my case, I kept it for the RAW SPEED.
> That's why I used stripeing on my game machine :)
Interesting that probably most RAID 1 controllers also
incorporate higher throughput.
Also, maybe I had better make sure I understand exactly
what striping two hard disk drives does? My assumption
is that with two identical hard disk drives, striping places
half of the data on one drive and half on the other drive
interleaved in some manner so as to increase throughput.
Actually, this last sentence of yours is 99.9% of why I am
responding. I have NEVER used striping. If I assume
that I have two hard disk drives and use striping, can you
suggest what the probable increase in throughput will be
as compared with a single hard disk drive.
(a) If I copy from one hard disk drive to a second hard
disk drive (without striping), I can copy about 1 GByte
per minute.
(b) I don't know if it is even possible, but if I operate with
striping using four identical hard disk drives which use striping
in pairs (i.e. the operating system thinks there are ONLY
two hard disk drives which are each double the size of
any single drive), what would the likely increased throughput
be assuming that the throughput limit is due to the hard
disk drives in each situation, neither the PCI controller nor
the motherboard memory (bandwidth in each case) being the
limitation? Basically, I think my question is whether the
firmware on the PCI controller is smart enough AND
fast enough to combine (or de-combine) a buffer
of information for a READ (or a WRITE) request from
two separate sources.
I realize that making one double sized drive from two
smaller ones is helpful in and of itself, but I really can't
see how striping can increase the throughput by very
much if I am using really fast EIDE drives in the first place?
Sincerely yours,
Jerome Fine
--
If you attempted to send a reply and the original e-mail
address has been discontinued due a high volume of junk
e-mail, then the semi-permanent e-mail address can be
obtained by replacing the four characters preceding the
'at' with the four digits of the current year.
Received on Fri Apr 26 2002 - 11:38:50 BST