• Subject: Re: 8G as a 4G replacement
  • From: Chuck Lewis <clewis@xxxxxxxxxx>
  • Date: Mon, 08 Jan 2001 16:16:08 -0500

Thank you Terry !

We are adding not replacing. I was aware that the 4 would (just) make a RAID 
set but was really concerned about the mix and performance
!

Appreciate your information !

Chuck

Terry.Rhoades@blum.com wrote:

> Hi Chuck,
>
> According to the AS/400 Redbooks......
> The #2726 PCI Raid Disk Unit Controller supports a maximum of 15 one or 
>two-byte disk units.  A minimum of four disk units of equal
> capacity are required to implemnet RAID-5 protection.  A maximum of 10 disk 
>units per RAID-5 array are supported.  Parity
> information can be spread across four or eight disk units.  A maximum of 
>three RAID-5 arrays are supported on one #2726.  Disk units
> not supported in a RAID-5 array can be attached to the #2726 in wither 
>unprotected or a mirrored environment.
>
> Therefore.......
> If I understand your situation correctly,  you should be able to ADD the four 
>8.58 GB disks (as a RAID-5 array) to your AS/400 and
> still have the option of adding another 4 disks as another RAID-5 array 
>later.  You should not see any performance problems with
> this configuration.
>
> However if you are REPLACING the six 4 GB disks with four 8.58 GB disks, you 
>will see some performance decrease because you will
> have fewer arms retrieving the information.
>
> Good Luck!
>
>
>                     Chuck Lewis
>                     <clewis@iquest.net>        To:     MIDRANGE-L@midrange.com
>                     Sent by:                   cc:
>                     owner-midrange-l@mi        Subject:     Re: 8G as a 4G 
>replacement
>                     drange.com
>
>
>                     01/08/01 02:53 PM
>                     Please respond to
>                     MIDRANGE-L
>
>
>
> We are running a 620-2179 with 6 of the 4GB drives (6607's). We need to add 
>more
> disk and have been quoted for 4 of the 8.58GB drives...
>
> I am CLULELESS on how this sets up. We have the 2726 Disk Storage Controller 
>and
> that is what the disk and the optical (CD) are on.
>
> Is this (adding these drives) going to create a problem ? We need more storage
> but is this going to hurt performance ?
>
> Thanks !
>
> Chuck
>
> Larry Bolhuis wrote:
>
> > > No way.
> >
> >   Rats.
> >
> > > This problem will continue to get bigger and bigger, and will particularly
> > > plague customers in the future when the minimum disk size could 
>potentially
> > > grow to 17GB, 35GB and then 70GB if we follow the progression of where we
> > > have been.
> >
> >   I certainly agree, many of the smaller systems out there already
> > streached to get 4-4G units just to have RAID. 4-8G units when purchased
> > new isn't so bad as the prices keep falling, but for the poor guy that
> > want's to add 4G, he basically has to go used.
> >
> >   I think the biggest problem we will deal with is as Charly mentioned
> > earlier: Arm count, or more correctly the LACK of arm count.  Already
> > you can't cram enough arms in a 170 to feed the CPUs, how bad is it when
> > we're pouring in 17G (or bigger) drives!
> >
> > > If you have a need for a 20 GB system, and the minimum DASD size is 70GB,
> > > what do you do for protection.  In that case, the correct answer may be
> > > mirroring.  BTW, mirroring will help with the arm contention problem.  But
> > > what happens if you need with growth to have a system at 140 GB usable, 
>and
> > > the minimum disk size is 70 GB.  Raid-5 requires a minimum of four devices
> > > in a parity set!
> >
> >   It is my opinion that IBM should continue to sell the smaller drives,
> > even if they are just the larger ones with 'crippling' jumpers or
> > microcode included (and I have told Mr Jarosh that for the good it'll
> > do.) Heck, at this point even if they priced them THE SAME as the bigger
> > drive the customer would save money. IBM has made good strides getting
> > the entry level systems down in cost but then swat the poor customer
> > across the face when they want 'just a little more storage'!
> >
> >   - Larry
> >
> > --
> > Larry Bolhuis
> > Arbor Solutions, Inc.
> > (616) 451-2500
> > (616) 451-2571 -fax
> > lbolhuis@arbsol.com
> > +---
> > | This is the Midrange System Mailing List!
> > | To submit a new message, send your mail to MIDRANGE-L@midrange.com.
> > | To subscribe to this list send email to MIDRANGE-L-SUB@midrange.com.
> > | To unsubscribe from this list send email to MIDRANGE-L-UNSUB@midrange.com.
> > | Questions should be directed to the list owner/operator: 
>david@midrange.com
> > +---
>
> +---
> | This is the Midrange System Mailing List!
> | To submit a new message, send your mail to MIDRANGE-L@midrange.com.
> | To subscribe to this list send email to MIDRANGE-L-SUB@midrange.com.
> | To unsubscribe from this list send email to MIDRANGE-L-UNSUB@midrange.com.
> | Questions should be directed to the list owner/operator: david@midrange.com
> +---
>
> +---
> | This is the Midrange System Mailing List!
> | To submit a new message, send your mail to MIDRANGE-L@midrange.com.
> | To subscribe to this list send email to MIDRANGE-L-SUB@midrange.com.
> | To unsubscribe from this list send email to MIDRANGE-L-UNSUB@midrange.com.
> | Questions should be directed to the list owner/operator: david@midrange.com
> +---

+---
| This is the Midrange System Mailing List!
| To submit a new message, send your mail to MIDRANGE-L@midrange.com.
| To subscribe to this list send email to MIDRANGE-L-SUB@midrange.com.
| To unsubscribe from this list send email to MIDRANGE-L-UNSUB@midrange.com.
| Questions should be directed to the list owner/operator: david@midrange.com
+---

This thread ...

Replies:

Follow On AppleNews
Return to Archive home page | Return to MIDRANGE.COM home page

This mailing list archive is Copyright 1997-2020 by midrange.com and David Gibbs as a compilation work. Use of the archive is restricted to research of a business or technical nature. Any other uses are prohibited. Full details are available on our policy page. If you have questions about this, please contact [javascript protected email address].