Hi, quick(?) Q: DP fg vol, source vol got a constituent added, auto-x added constituent to DP fg vol and then failed to snapmirror new constituent. Started new DP fg vol, set up new SM, etc, this happens with larger vols a lot in our company, so nothing new. Fiddled around and decided to del new constituent on anyway broken old DP vol. Is there a way to get this old vol online again, only using the old constituents? The last one never got SM'ed over. vol stays in mixed-state, all 'old' constituents are online, but virtual vol still seems to know about it's new constiuent, as constituent-count = actual existing constituents +1. Thanks!
#Force online flexgroup vol with 1 constituent missing?
1 messages · Page 1 of 1 (latest)
Ah, found flexgroup refresh. Problem solved.
Hm, vol looks healthy now, all online, junction (path) active. No access from admin client via NFS (not a policy problem). Also internal CLI commands accessing data on vol hang, e.g. 'security file-directory show', etc. Ideas?
I'm a little lost here. Can you show some output showing the problems and errors you're getting?
Is it like NFS server not responding?
Or doing a mount from a NFS client hangs?
(just obfuscate any PII)
No output on NFS access, just hangs. Access (ls) via SVM's global namespace hangs in getdent() of the folder (/vol in our case) containing the Ontap mount on the linux nfs client. Ontap CLI access via 'vserver security file-directory show /vol/volxy/some/path' hangs, need to kill the CLI session via another one. I have taken the vol offline again now, otherwise our administrative NFS client doing the backups hangs. I have checked logs on the underlying nodes (in systemshell), nothing really unnormal, vol seems fine. No event logs, vol and it's constituents all look good. Just untouchable. I guess too much playing killed it. Not too important, just asking for fun and some time saving, as new SM initialize will take 10+ days, sites are 1500 km apart.
I tried all obvious and learned over 20+ years of tricks on the NFS and Ontap side, so this seems some funny problem.
Any errors in EMS?
and have your logged a case and what is the case number?
0 errors. Not important enough, no time, already know answer (ditch vol, reinitialize mirror from source). This happened very often in other sites of our shop, to an extent they've ditched 100s of PBs of NetApps, so nothing new here. SMs of really large fg vols which get extents added on the source has been a challenge.
I have asked here to get a quick fix if it would have existed, so all good.
Without having a look at the system I have no idea.
added constituent to DP fg vol and then failed to snapmirror new constituent
so the general takeaway for NetApp appears to be that they need to better communicate that adding constituents in a flexgroup with a DP mirror needs an extra step. And not just document that step online where nobody will read it, but add the warning in the CLI and SM. Perhaps add an auto-initialize for newly added constituents. Something to help prevent customers from shooting themselves in the foot.