This post is more than 5 years old
74 Posts
0
10916
IPC error cancelling volume migrations
Hello,
I kicked off approximately 30 volume migrations from one pool to another. Pool-1 is 3x PS6500E using 1TB drives, and pool-2 is 2x of the same. As far as I can tell, the progress is OK, but slow. I actually wanted to cancel a few of the moves, but receive "IPC error" from both the GUI and the CLI.
Just wondering if anyone had any ideas before I file a case.
Firmware 5.0.4.
Cheers,
Eugene
evilensky
74 Posts
1
April 5th, 2011 09:00
Sound advice, but as we waited for a call-back, many volumes finished up, and we were able to cancel further ones without trouble. I guess the lesson is to queue up only a few operations at a time for a busy group. I have no doubt those little ARM chips are working their hearts out for us, but note to Dell: it might be worth documenting or enforcing such limits...
Anonymous
5 Practitioner
5 Practitioner
•
274.2K Posts
0
March 29th, 2011 17:00
Hello,
For something of this nature, please open a case with support. They can gather diags and determine what the issue is.
With that many moves queued up the array could just be too busy moving volumes and servicing IOs at the same time to update the GUI.
Only a review of the diags would show that.
Also making sure your network is configured correctly is important too. Things like flowcontrol and making sure the inter-switch links are sufficient to handle the migration.
Regards,
-don
mfkelly_tx
31 Posts
0
April 7th, 2011 05:00
I sent in a huge feature request list, a couple of firmware releases ago, that included controller CPU utilization monitoring. This can happen with any management task, including observing the properties of a volume, resizing, etc.
Also, anything considered a "feature" will not function while the CPUs are over-utilized, i.e. autoraid, etc.
To view the utilization requires calling support and logging in as root to run the support scripts.
Changing of the group lead is not dynamic either, you could have a member in your group doing nothing and if the GL's CPU is maxed out it will just remain the GL until some manual intervention is performed, like calling support and getting the scripts for forcing the change, or vacating, removing and re-adding the member.
mfkelly_tx
31 Posts
0
April 7th, 2011 08:00
The default RAID type of a volume is AUTO. If you have more than one RAID setting within a pool, like one member is RAID10 and the other RAID50 the volumes will automatically migrate to the appropriate RAID for the data type based on an algorithm run on the group lead that decides what is best. This "feature" is one that will not occur for you while the GL's CPU is under heavy load.
evilensky
74 Posts
0
April 7th, 2011 08:00
Hi,
I must've missed it in the docs, but what is auto RAID? Load balacing within a pool, or the actual raid operations of a member are in trouble when CPU is busy?
Cheers,
Eugene