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



Sadly the RAID build time cannot be avoided.

Scenario: SAVE 21 / Swap in 280's / RESTORE 21.

You will spend 'MANY Minutes' to initialize the LS Disk during the restore.
You will then spend 'MANY MANY Minutes' to start RAID (about 6 hours)
THEN you will do the install the OS and restore of everything else.

Scenario: Swap and Pull and Copy as initially described.

As previously described building the RAID set will take est 6 hours.

Scenario: Initialize the RAID set on some other machine so that RAID doesn't have to be started. Then use the top scenario above.

You will spend 6 hours initializing the LS disk!
Then you will restore.

Fact is the 280 GB disks will take time to implement. That's just the facts.

- DrF

On 7/15/2011 4:13 PM, Charles Wilt wrote:
I believe the build time will greatly out last the time for a save/restore...

Not to mention this process would be a heck of a lot riskier than
save-swap-restore...

Charles

On Fri, Jul 15, 2011 at 3:57 PM, Kirk Goins<kirkgoins@xxxxxxxxx> wrote:
Be prepared for a very long RAID build on that size drive... especially
since there will be data on the drives.

On Fri, Jul 15, 2011 at 12:38 PM, John Jones<chianime@xxxxxxxxx> wrote:

DrFranken, so is what you're describing the following:
1. GO SAVE/21
2. End RAID5 *At this point the system has no protection from disk
failures*
3. Disk-by-disk, logically remove each 70GB disk via SST, replace it with a
280GB, and add the 280GB to the ASP
4. Do a load source migration type of trick to move the load source
5. Re-establish RAID5 to gain protection from disk failure
6. Probably do some form of STRASPBAL when done

Re: Item 5: IDK about 525s but on our Power5+ 570 we IPL one V6R1 LPAR from
280GB SCSI disks (4329s on a 2780).

On Fri, Jul 15, 2011 at 1:54 PM, DrFranken<midrange@xxxxxxxxxxxx> wrote:

Yes. (this is totally crazy)

You will need to take the system down during part of this at least.

1) You cannot use a 140 or 280GB Drive to replace a 70GB drive in a RAID
set. Even if you could (as some vendors allow) it would be treated as a
70GB drive.

2) You cannot replace the Load Source disk unit without an IPL in any
case.
3) Replacing drives in the manner of which you speak can mostly be done
live but YOU ARE EXPOSED during 100% of the swapping. A disk failure
between the beginning of 'STOP RAID' to the completion of 'START RAID'
at the end means *RELOAD. As a consequence a SAVE 21 (maybe 2?) before
you start is mandatory and if the system is running production you still
could lose that. It can work but not without at least one IPL PER DISK
PULL. (More than one disk could be pulled at a time.)

4) NOte that if you are on V7R1 the disks can be completely removed
without an IPL (except the Load Source.)

5) I do not believe you can IPL from a 280GB Disk unit on a 525. There
was a restriction there and I *think* it's still there for SCSI drives.
So 140 GB units are best choice.

- Larry 'DrFranken' Bolhuis

On 7/15/2011 2:03 PM, Johnny Lee Lenhart wrote:
Hi there:

We have a 9406-525 with 8 4327 (70 GB) disk drives in a single RAID
set.
The drives are in the system enclosure and there are no additional
slots
available. We are at 85% DASD utilization.

We have an idea for increasing our DASD capacity without taking our
system down. Our thought is that we could fail one of the 4327 drives,
replace it with a 4328 (140 GB) or 4329 (280 GB) and let the RAID
controller rebuild it, and that we could do this one-by-one until we
have replaced all of the drives, thus doubling or tripling our current
DASD.

Is this totally crazy? One person I've talked with suggested that you
can't have mixed sized disks in one RAID array, but our network admin
thinks we did have this in an 810 we used to run. Someone else thought
that we might have issues increasing our DASD capacity without
increasing disk arms, but our current performance metrics don't seem to
support that concern. At any rate, we are willing to take that risk.
Our main interest right now is answering the question about whether or
not this disk-at-a-time replacement into the same RAID array is
possible. We really can't afford to have our system down for the time
it would take to do the backup/change disks/restore method.

Thoughts?

Thanks,

Johnny Lee Lenhart
Sr. Technical Specialist
Brattleboro Memorial
Hospital
Brattleboro, Vermont USA


_______________________________________________________________

The information contained in, or attached to, this e-mail, may contain
confidential information and is intended solely for the use of the
individual or entity to whom it is addressed and may be subject to legal
privilege. If you have received this e-mail in error you should notify
the
sender immediately by reply e-mail, delete the message from your system
and
notify your system manager. Please do not copy it for any purpose, or
disclose its contents to any other person. The views or opinions
presented
in this e-mail are solely those of the author and do not necessarily
represent those of the company. The recipient should check this e-mail
and
any attachments for the presence of viruses. The company accepts no
liability for any damage caused, directly or indirectly, by any virus
transmitted in this email.
_______________________________________________________________
--
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.



--
John Jones, CISSP
--
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.



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

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.