On Fri, 1 Dec 2000 09:00:53 -0600 (Central Standard Time), Andreas
Schmidt <[log in to unmask]> wrote:

>for MPE:
>
>RAID 1 is a one-to-one mirroring. duplicates disk space and H/W.
>
>RAID 5 uses parity information on one disk. better for disc space
>requirements but if a disk fails the missing info must re-calculated for
>each byte as part of the RAID H/W.
>We had RAID 5 with 3 or 5 disks where 2 or 4 have been used netto (2/3 or
>4/5 of named disccap could be used).

Actually, RAID 5 puts parity information on ALL disks in the RAID 5
set. RAID 3, however, has a dedicated parity disk like you describe.
This difference has implications for write performance and
serialization vs. concurrence of multiple disk I/O requests.





>
>RAID 0 is NO RAID (?! but it is named RAID)
>RAID 2 to 4 are in between 1 and 5, distinguished by the formular and
>stripping methods used accross several disks. I read this a while ago and
>could look for more details if needed.
>
>Best regards, Andreas, CSC, Germany
>
>
>
>
>
>
>"Johnson, Tracy" <[log in to unmask]>@RAVEN.UTC.EDU> on 01/12/2000
>03:35:06 PM
>
>Please respond to "Johnson, Tracy" <[log in to unmask]>
>
>Sent by:  HP-3000 Systems Discussion <[log in to unmask]>
>
>
>To:   [log in to unmask]
>cc:
>Subject:  Re: [HP3000-L] Mirrored Disk vs. Raid
>
>
>I seem to get the opinion in conversations in a
>similar vein to the HP3K vs 'x'.
>
>i.e. That mirroring is 'old technology' vis-a-vis
>'RAID' and why do I still use it?
>
>Could someone post what all the RAID-n version
>differences are?
>
>Tracy Johnson
>MSI Schaevitz Sensors
>
>
>-----Original Message-----
>From: Sletten Kenneth W KPWA [mailto:[log in to unmask]]
>Sent: Thursday, November 30, 2000 8:43 PM
>To: [log in to unmask]
>Subject: Re: Mirrored Disk vs. Raid
>
>
>Several people noticed that "Holloway, Rich" wrote:
>
>> Hp has indicated the low priority is due to plans to drop
>> the Mirror/ix product.
>
>Bill Lancaster provided a "non-HP" answer:
>
>> .........  Finally, someone mentioned that HP's plans are to
>> eliminate Mirrored Disk/iX.  I don't believe that to be the case.
>> For one thing, many, many customers use the product.
>> Second, there is no good reason to eliminate a product that
>> is in wide use and has matured to the point where there isn't
>> any active, major development against it.  Third, it would raise
>> a significant hue and cry.  Last, it is an excellent solution,
>> if chosen wisely.
>
>Speaking as just one end-user, <bold-face> and <underline>
>on "significant hue and cry":  Using a little funding we managed
>to latch on to before somebody beat us to it, I just bought four
>more hot-swap modules with ST39173WC discs for our two
>A3312A HASS units;  i.e.:  We are fully committed to Mirror/iX.
>If that product was to "go away" any time while we are still
>running our current 959-400, any attempt by me to go to my
>managers and ask for what amounts to major $ (for us) to go to
>hardware mirroring would have unhappy results:
>
>(1)  I would not get the $$.
>
>(2)  We would with renewed emphasis again get asked:  "How
>long would it take to port our in-house client-server app to NT
>and SQL/Server ??
>
>
>While I tend to expect that the real situation is as Bill related it,
>I also doubt that Rich pulled "HP has indicated the low priority
>is due to plans to drop the Mirror/ix product" out of thin air....
>Given the seriousness of the question that has been raised, it
>would improve my "comfort level" if someone from HP would
>(hopefully) deny that Mirror/iX is going away any time soon...
>
>...  Maybe it is the Mirror/*UX* product that is going away (think
>I heard / read that somewhere a while back) ????
>
>
>Back to a technical Mirroring issue....:  Bill also noted:
>
>> ........ 2.  Keep the production data protected with Mirrored
>> Disk/iX but add Model 20 disk arrays to protect your system
>> volume set.  I already mentioned a concern about this option.
>
>Realizing that it is not an ideal "solution", I came up with what I
>would like to think is a "poor man's" improvement over our
>current exposure for our non-mirrored and non-arrayed
><long_name>; given that we have two HASS enclosures that
>will continue to have at least two out of eight spindle slots empty.
>Here's the plan (critical technical reviews gratefully accepted):
>
>Note our current <long_name> "baseline" is four 2GB internal
>discs in the 959 SPU cabinet....
>
>
>(1)   Two of the new 9GB hot-swap HASS modules that are "in
>the mail" will be kept on the shelf as "hot spares" (after rotating
>them through one of our existing mirrored volume sets to verify
>they are good).  That way if one spindle blows up we can pop
>in a good spare while still having one more spare in reserve;
>(hopefully) allowing us to leisurely order a replacement spare
>(about a grand per module, last reputable-vendor price we got).
>
>
>(2)   The other two new 9GB modules will be installed in two
>empty slots in ONE of the HASS enclosures as the new
>MPEXL_SYSTEM_VOLUME_SET.  After making sure that our
><long_name> is well backed up, I will reconfigure to put LDEV
>1 and LDEV2 on those two external 9GB drives in the one
>HASS enclosure (which has the optional second power supply
>and both fans); and follow with INSTALL of <long_name> only.
>
>SIDEBAR:  Our <long_name> is 99.99 percent "HP pure";  i.e.:
>Not only all our user data but also all third-party accounts are
>on one of three mirrored user volumes....  so we've only got
>6.5 million sectors on our <long_name>....  Plus we have 1792
>MB memory, so figure two 9GB spindles will get us by for our
><long_name> (realizing that at least one more spindle for that
>would have been nice (which we can add that later if my
>guesstimate is wrong and I scrounge a few more bucks) ).
>
>
>(3)   After (hopefully again) successfully completing above two
>steps, if any of our spindles in either of the HASS units fails, we
>will have two common spares on the shelf.  If a <long_name>
>spindle failure occurs with that volume resident in HASS, then
>figure out whether LDEV 1 or LDEV 2 died;  pop in hot spare;
>and do quick INSTALL of <long-name> only.
>
>Granted that takes us down for up to an hour or so total (actual
>INSTALL time ~15-20 min last time we proactively replaced
><long_name> spindle;  when predictive warned it was starting
>to have problems (INSTALL much faster the byte-wise disc-to-
>disc copy utility) ).  While this won't fly for those who absolutely
>cannot tolerate being down for even one hour during the day,
>given expected frequency of 9GB spindle burn-out and the fact
>we don't have the $$ for an array anyway, above was best
>achievable solution I could come up with in our real world...  It's
>certainly a whole bunch quicker than waiting up to a day with
>the system down for the HP CE to arrive on-site with a new
>spindle.....
>
>Ken Sletten
>