× The internal search function is temporarily non-functional. The current search engine is no longer viable and we are researching alternatives.
As a stop gap measure, we are using Google's custom search engine service.
If you know of an easy to use, open source, search engine ... please contact support@midrange.com.



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.


As an Amazon Associate we earn from qualifying purchases.

This thread ...

Follow-Ups:
Replies:

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

This mailing list archive is Copyright 1997-2024 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].

Operating expenses for this site are earned using the Amazon Associate program and Google Adsense.