EMC – Check on a RAID Group’s defragmentation progress with naviseccli

For those of you still using RAID Groups on the CX4, you’ll know that you sometimes need to defragment them to get a contiguous amount of free space, particularly if you’ve unbound LUNs in the group that sit between other, remaining LUNs. If you kick off a whole bunch of defrags and then want a quick way to check the progress, why not use naviseccli? The getrg option is the one you want to use in this example.

naviseccli -h 256.256.256.256 getrg -prcntdf

The output will look something like this:

RaidGroup ID: 0
Percent defragmented: 100
RaidGroup ID: 1
Percent defragmented: 100
RaidGroup ID: 2
Percent defragmented: 100
RaidGroup ID: 3
Percent defragmented: 1
RaidGroup ID: 4
Percent defragmented: 1
RaidGroup ID: 5
Percent defragmented: 100
RaidGroup ID: 6
Percent defragmented: 2
RaidGroup ID: 7
Percent defragmented: 1
RaidGroup ID: 8
Percent defragmented: 100

 

RAID Group defragmentation halted

It only happened last month, but it feels like decades ago. As part of a data migration project I’ve been working on, I needed to defragment a SATA RAID Group on a CX3-20. Knowing it was going to take a while, I went and did some other things. When I cam back to it 24 hours later, however, it was still sitting on 0%. Hmmm, that seems like it’s taking a while. So I started digging around and noticed that the SP event logs mentioned something about “Expansion process halted” or some such. Okay, cool, so why has it halted? And why isn’t there a button marked “Resume”? The EMC KB article emc178703 – “LUN expansion halted after defragmentation operation started” gives some indication that one of the LUNs may have trespassed after the expansion process had started, and this was why the process had halted. The solution was to trespass the LUN back to its original owner. However, according to the article, this was a scary move, and you need to engage engineering, or marketing, or someone I can’t remember, to assist in identifying the correct LUN. Well, while that was an option, it wasn’t terribly appealing, so I decided to trespass the LUNs myself (I’m much more cautious when it comes to my own data).

So I attempt to migrate one of the LUNs in the RAID Group back to its owner. No dice. Some error along the lines of “You are not allowed to transfer LUN”. Sorry for the vagueness, but my notes were quite sketchy after working on this for a few days over the weekend and going to sleep dreaming of Incremental SAN Copy setups. But I digress. MirrorView/Synchronous was active on some of the LUNs as they were secondary images for some Remote Mirrors we had in play. Cool, so how do I fix this? I realised that the source LUN was owned by SP A, and the secondary image was owned by SP B. So MirrorView, rightly so, had trespassed the secondary to be on the same SP as the source. By admin-fracturing the mirror, changing the default source LUN owner, trespassing the source and re-synchronizing, I was able to get MirrorView to automatically trespass the destination LUN as well. Wonder of all wonders, the defragmentation continued after that, and finished a lot sooner than I’d expected. Although really, it would have been good to know that this could be a problem before it became a problem.