Re: Removing (unconfigured) disks from RAID-5 array?

[Midrange <midrange@xxxxxxxxxxxx>]

Yep. 3 drive sets start as 2 with stripe and 1 without. 4-7 drive sets start with 4 with stripe and 0-3 without. I believe it's 8-15 then which start with 8 drives with stripe and then 0-7 without.

Remember that's all SCSI stuff.  SAS Tosses that out the window....

   DrFranken

Sent from my iPad

On Aug 19, 2013, at 9:30 AM, rob@xxxxxxxxx wrote:

> So, even if they started out with a three drive raid set, it only put the 
> raid striping on 2 of the three drives?  Odd.  Then again, so is a three 
> drive raid set.  The math almost makes sense.  Take one drive (17gb) out 
> for raid striping. Divide that by 2 is roughly 8.5.  So that would make 
> two drives look like roughly 8gb drives.  Yep, as another poster 
> suggested, we need the drive type of these drives from WRKDSKSTS.  Even 
> better would be both the "type" and the "model" from STRSST, 3. Work with 
> disk units, 1. Display disk configuration, 1. Display disk configuration 
> status.
>
> If this is the case, then removing RAID from all of these drives and 
> turning it back on thus putting the stripe across ALL drives might really 
> increase performance.
>
> You could still chop them up into alternate ASP's if you wanted to.  Even 
> if they are all in the same raid set.  I'm not a big fan of that though. 
> Mainly because islands of disk is more management.  Let's see, where do I 
> put this new library?  ASP x or y?  Which is logical?  Which has the 
> space?
> And, unless you have lots of drives, on different controllers, and you 
> want to keep receivers on a different set of arms than on your DB arms, I 
> can't see any perform increase by multiple ASPs.  And, it's not like this 
> old AS/400 with teeny tiny disks is concerned about keeping new SSD's in 
> their own ASP to segregate data which requires high read performance.
>
>
> Rob Berendt
> -- 
> IBM Certified System Administrator - IBM i 6.1
> Group Dekko
> Dept 1600
> Mail to:  2505 Dekko Drive
>          Garrett, IN 46738
> Ship to:  Dock 108
>          6928N 400E
>          Kendallville, IN 46755
> http://www.dekko.com
>
>
>
>
>
> From:   Midrange <midrange@xxxxxxxxxxxx>
> To:     Midrange Systems Technical Discussion <midrange-l@xxxxxxxxxxxx>, 
> Cc:     Midrange Systems Technical Discussion <midrange-l@xxxxxxxxxxxx>
> Date:   08/19/2013 10:09 AM
> Subject:        Re: Removing (unconfigured) disks from RAID-5 array?
> Sent by:        midrange-l-bounces@xxxxxxxxxxxx
>
>
>
> Pete is likely correct and I'm guessing the set started out with only 
> three drives. Thus two only had striping making them 8GB usable and the 
> third got the full 17GB.  All the rest were likely added later so they 
> also show the full 17GB usable.  Performance could be quite poor on such a 
> set especially with a failed drive!
>
>    DrFranken
>
> Sent from my iPad
>
> On Aug 19, 2013, at 7:25 AM, rob@xxxxxxxxx wrote:
>
> > Pete,
> >
> > It's been a long time since I've seen such small disks but would raid 
> > striping really explain the difference between 8 and 17GB drives?  That,
>
> > and the fact that he only has two 8gb drives makes me suspect it's not 
> > raid striping that causing the difference.  Because, as you've noted,
> you 
> > have to have at least three drives in a raid set, preferably four or
> more.
> > Basically, when you do raid striping you lose one drive, spread out over
>
> > all the drives doing the striping.  For example, on one lpar I have two 
> > parity sets.  I combined two screens to show this:
> > One:                 Size
> > Unit  Type Mode       (M)
> > 14  4327  070     70564
> > 12  4327  070     70564
> > 13  4327  070     70564
> > 10  4327  074     52923
> >  9  4327  074     52923
> >  8  4327  074     52923
> >  7  4327  074     52923
> > Two 
> > Unit  Type Model 
> >  2  4328  074    105847
> >  3  4328  074    105847
> >  4  4328  074    105847
> >  5  4328  074    105847
> >  6  4328  070    141129
> >  1  4328  070    141129
> > 17  4328  070    141129
> > 16  4328  070    141129
> > 15  4328  070    141129
> > 18  4328  070    141129
> > 11  4328  070    141129
> > The 074's contain the raid strip and lose some disk space.  And if you
> add 
> > up the size difference (141129-105847) and multiply that by the number
> of 
> > 074's (4), you get the size of one disk (140gb).  Or (70564 - 52923) *
> (4) 
> > = 70gb.
> >
> > Yes, a three drive raid set, while supported, is a performance killer.
> And 
> > that's cross platform (IBM and others).  Four or more makes a huge 
> > difference.
> >
> >
> >
> >
> > Rob Berendt
> > -- 
> > IBM Certified System Administrator - IBM i 6.1
> > Group Dekko
> > Dept 1600
> > Mail to:  2505 Dekko Drive
> >         Garrett, IN 46738
> > Ship to:  Dock 108
> >         6928N 400E
> >         Kendallville, IN 46755
> > http://www.dekko.com
> >
> >
> >
> >
> >
> > From:   Pete Massiello - ML <pmassiello-ml@xxxxxxxxxxxx>
> > To:     Midrange Systems Technical Discussion <midrange-l@xxxxxxxxxxxx>,
>
> > Date:   08/19/2013 07:48 AM
> > Subject:        RE: Removing (unconfigured) disks from RAID-5 array?
> > Sent by:        midrange-l-bounces@xxxxxxxxxxxx
> >
> >
> >
> > You can't have multiple sized disks in the same parity set, my bet is
> that 
> > these are the same physical sized disks, but these disks have all the 
> > Raid5 stripes on them and some of the other disks in the set were added 
> > later.
> >
> > If they are unconfigured, meaning they show up as unit 0 in WRKDSKSTS at
>
> > the bottom, then you need to stop partity on these.  You might have to 
> > stop parity on the entire set, remove these drives, and then restart
> back 
> > on the remaining disks. 
> >
> > When you add or  remove RAID, it does NOT destroy any data on the disks.
>
> > The beauty of IBM i. You need a min of 3 disks (which you will have poor
>
> > performance on as these look like SCSI disks from the size) for RAID5. 
> > Unsure of what your reasons are for putting the disks into a separate
> ASP, 
> > but you could keep them in the same raid set and put them into a
> different 
> > ASP.
> >
> >                Pete 
> >
> > --
> > Pete Massiello
> > iTech Solutions
> > http://www.itechsol.com
> > http://www.iInTheCloud.com
> >
> >
> >
> >
> > -----Original Message-----
> > From: midrange-l-bounces@xxxxxxxxxxxx [
> > mailto:midrange-l-bounces@xxxxxxxxxxxx] On Behalf Of Rene K.
> > Sent: Monday, August 19, 2013 5:11 AM
> > To: midrange-l@xxxxxxxxxxxx
> > Subject: Removing (unconfigured) disks from RAID-5 array?
> >
> >
> > Hi All,
> >
> > apparently two 8GB disk that I left unconfigured are not only in the 
> > System ASP (as by design), but also part of the (RAID-5) parity
> protection 
> > of 4x 17GB disks.
> > Why this happened I don't know, let's just call it inexperience :)
> >
> > I wanted to move the 8GB disks to a User ASP and mirror them, but the 
> > system won't let me. I don't really need the 8GB disks, but I think it's
>
> > better to keep the RAID array 'clean' by using similar sized disks.
> Maybe 
> > this move also changes the RAID-5's status from 'unprotected' to 
> > 'protected' ('Display Disk Configuration Status' screen shows ASP 1 as 
> > 'unprotected', while all four disks show 'RAID-5/Active'??).
> >
> >
> > Documentation seems to say that I have to stop parity protection to move
>
> > the disks to another ASP, but in my world, 'stopping/destroying a RAID 
> > array' means 'loosing all data that's on that array'.
> >
> > My question is: is it possible in i5/OS V5R4 to stop parity protection, 
> > move the 8GB disks to another ASP, and enable parity protection on the 
> > disks in ASP 1 again, without having to reinstall the LIC/OS again?
> >
> > Thanks for any info,
> >
> > Rene,
> > Holland.
> > --
> > This is the Midrange Systems Technical Discussion (MIDRANGE-L) mailing 
> > list To post a message email: MIDRANGE-L@xxxxxxxxxxxx To subscribe, 
> > unsubscribe, or change list options,
> > visit: http://lists.midrange.com/mailman/listinfo/midrange-l
> > or email: MIDRANGE-L-request@xxxxxxxxxxxx Before posting, please take a 
> > moment to review the archives at http://archive.midrange.com/midrange-l.
> >
> > -- 
> > This is the Midrange Systems Technical Discussion (MIDRANGE-L) mailing 
> > list
> > To post a message email: MIDRANGE-L@xxxxxxxxxxxx
> > To subscribe, unsubscribe, or change list options,
> > visit: http://lists.midrange.com/mailman/listinfo/midrange-l
> > or email: MIDRANGE-L-request@xxxxxxxxxxxx
> > Before posting, please take a moment to review the archives
> > at http://archive.midrange.com/midrange-l.
> >
> >
> > -- 
> > This is the Midrange Systems Technical Discussion (MIDRANGE-L) mailing
> list
> > To post a message email: MIDRANGE-L@xxxxxxxxxxxx
> > To subscribe, unsubscribe, or change list options,
> > visit: http://lists.midrange.com/mailman/listinfo/midrange-l
> > or email: MIDRANGE-L-request@xxxxxxxxxxxx
> > Before posting, please take a moment to review the archives
> > at http://archive.midrange.com/midrange-l.
> -- 
> This is the Midrange Systems Technical Discussion (MIDRANGE-L) mailing 
> list
> To post a message email: MIDRANGE-L@xxxxxxxxxxxx
> To subscribe, unsubscribe, or change list options,
> visit: http://lists.midrange.com/mailman/listinfo/midrange-l
> or email: MIDRANGE-L-request@xxxxxxxxxxxx
> Before posting, please take a moment to review the archives
> at http://archive.midrange.com/midrange-l.
>
>
> -- 
> This is the Midrange Systems Technical Discussion (MIDRANGE-L) mailing list
> To post a message email: MIDRANGE-L@xxxxxxxxxxxx
> To subscribe, unsubscribe, or change list options,
> visit: http://lists.midrange.com/mailman/listinfo/midrange-l
> or email: MIDRANGE-L-request@xxxxxxxxxxxx
> Before posting, please take a moment to review the archives
> at http://archive.midrange.com/midrange-l.