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



Forgive me, my muddled brain was confusing parity sets with ASP's here.
Just ignore everything but the last sentence....

Regards,
Scott Ingvaldson
AS/400 System Administrator
GuideOne Insurance Group

-----Original Message-----
From: Ingvaldson, Scott 
Sent: Monday, October 27, 2003 4:11 PM
To: 'midrange-l@xxxxxxxxxxxx'
Subject: RE: Exposure with unprotected disk units


You probably "could" add the 17.5 G drives to the parity set with the 4 G
units, but I don't think that you'd want to.  We had a single 2 G drive in a
parity set with 8 G drives once and the 2 G drive got overworked and killed
the I/O in that set.  I was told that the rule of thumb was not to mix
drives more than 1 step apart in a parity set.  Of course the rules could be
different now but I would think that they would be more dependant on the
disk controller than the drives themselves.

If you had a parity set with 8.5 G drives in it I wouldn't hesitate to add
the 17.5's to it.  Other options would be to buy two more 17.5's to add to
this set and start parity protection (you'll lose 25% of the total DASD) or
just start mirroring and lose 50% (you'd be at 37.2% in this ASP.)

Regards,
Scott Ingvaldson
AS/400 System Administrator
GuideOne Insurance Group

-----Original Message-----
date: Mon, 27 Oct 2003 13:47:41 -0600
from: "Scott Lindstrom" <SLindstrom@xxxxxxxxxx>
subject: Exposure with unprotected disk units


In reviewing one of the old systems I am responsible for, I noticed that
some 17.54gb disk units were added onto the system (as ASP 3) and are in an
unprotected state.  I think if we had added 4gb disk units in these
locations, we simply could have added them to the existing parity set, but
since they are 17.54gb they can't be added.  Is this correct?

                                  Size     %    I/O   Request   Read  Write
Read  Write     %       --Protection--
Unit  Type    (M)  Used    Rqs  Size (K)    Rqs    Rqs    (K)    (K)  Busy
ASP  Type  Status
   1  6607   4194  84.8     .5      10.3     .3     .2   12.5    6.7     0
1  DPY   ACTIVE
   2  6607   3670  84.7     .5      15.3     .3     .2   18.6   11.4     0
1  DPY   ACTIVE
   3  6607   3670  84.7     .5      18.2     .2     .2   24.0   10.9     0
1  DPY   ACTIVE
   4  6607   3670  85.0     .5      11.7     .3     .2   17.2    4.9     0
1  DPY   ACTIVE
  17  6607   3145  23.8     .0       5.4     .0     .0    4.0    5.9     0
2  DPY   ACTIVE
   <snip>
  23  6714  17548  18.6     .1      56.9     .1     .0   66.8   37.4     0
3
  24  6714  17548  18.6     .2      67.6     .1     .0   76.6   50.2     0
3


What could I expect if we lost either drive 23 or 24?  Can the system ride
out the loss of a user ASP?  If not, and it crashes, when the failed disk
is replaced and the system is brought back up, is there any data loss in
the ASPs that *are* RAID protected? (This is a V4R4 system).

Scott Lindstrom
   
This message and accompanying documents are covered by the Electronic
Communications Privacy Act, 18 U.S.C. §§ 2510-2521, and contains information
intended for the specified individual(s) only. This information is
confidential. If you are not the intended recipient or an agent responsible
for delivering it to the intended recipient, you are hereby notified that
you have received this document in error and that any review, dissemination,
copying, or the taking of any action based on the contents of this
information is strictly prohibited. If you have received this communication
in error, please notify us immediately by e-mail, and delete the original
message.


As an Amazon Associate we earn from qualifying purchases.

This thread ...


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.