HPE Storage Users Group

Hi Guys,

I need to remove 4 newly added disks from a 3PAR P7200.

What is the best way to do this task? "Servicemag start" than "dismisspd" can do the job?

Thanks,
Ziad

I would not do servicemag because when you run the dismisspd the array will still think it is reallocating blocks temporarily. We ran into that when we re-balanced within the array. servicemg shodul only be used when data will be redirected back to the original disk position shortly.

First:
set ldalloc off <PDID>

Do this on all disks you want to remove before you dismiss. This will prevent new chunkets from being moved onto the disks from thinp, AO or the dismisspd process you are about to run.

Next:
dismisspd <PDID>

Once the disks show up in "new" status they can be removed. If you have optimization installed you can run tunesys to re-balance chunkets if needed after all of the disks are dismissed.

Do not run a servicemag command in this instance. It expects that the disk will be replaced and resumed.


-Bryan @ Match.com

_________________
Bryan W
Senior Architect/Manager of System Infrastructure, Dallas TX
https://www.linkedin.com/in/bryanlwhite

So dismisspd gracefully moves existing chunk lets off the disk? ....

I'm glad that works and super frustrated at the same time... We had a situation last year where we added a new tier (SSD) to existing large T800s and wanted to move about 16 drives around... opened tickets with support requesting alternatives to the customer driven "dynamic optimizer" method they supplied... I specifically asked about commands like that one as well as movepdtospare and got stonewalled. We had to tune over 250 VVs to new CPGs, then tune them back after the drives were moved.

_________________
Richard Siemers
The views and opinions expressed are my own and do not necessarily reflect those of my employer.

I think using tunevv to move the vv to a different CPG is the preferred method since it properly aligns the chunklets when it moves the data off. We used dismisspd to remove some drives and had to run tunesys to realign the data on the disks afterwards.
It sounded like the original poster had recently added the drives so I didn't figure they were a lot of active chunklets.

That said if you didn't want to tunevv every vv, you could just plan on using tunesys -cpg against the affected CPGs after moving the disks around (all assuming you have DO). At least it is less commands to run.

Bryan @Match.com

_________________
Bryan W
Senior Architect/Manager of System Infrastructure, Dallas TX
https://www.linkedin.com/in/bryanlwhite

Your array is 3.1.1 or higher:
- use setpd ldalloc of pdid to stop allocation of chunklets on this pd
- movepdtospare -f -vacate pdid to reallocate any used chunklets to other disks of same type
- removespare pdid:a to remove any spare chunklet
- dismisspd pdid to remove pd from conf. it will be marked as New

Thank You for the update, I already tried successfully the steps.

Good Day.

I have a couple of questions about the procedure meintioned in RitonLaBevue post above.

When trying movepdtospare or alternatively movepd I get an error:

What does it mean? I dont have any degraded disks, last time a disk had failed was more than a year ago. Or is it some leftover from servicemag command that I tried to use a couple of days ago? But currently it shows



My system runs 3.2.1 MU2

I've been having a similar issue. After several calls to HP they sent me this command list (using PDID 12 as an example). When step one errors out run it again with the '-dr' flag. Take note of the degraded chunklets and run step two against each of them. After running against all the degraded chunklets step one has kicked off fine.

Steps to Remove/Replace a PD:


Again - the movech had to be run against each chunklet reporting degraded. Luckily, I only had two on this PD.
My best guess (and it is a guess) after talking to a different 3PAR tech is that in my case the degraded/remote_disks_used means that a disk on a different node was required.

Thanks a lot cmarcus, movech command indeed helped.