× 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.



I
wasn't aware SAS did RAID any different...

How does SAS work?

Charles


On Mon, Aug 19, 2013 at 12:02 PM, Midrange <midrange@xxxxxxxxxxxx> wrote:

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.

--
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.