PowerScale API Concurrency Limitations During Failover/Failback
This advisory applies to Eyeglass DR environments running multiple concurrent failovers with a high number of SMB shares per SyncIQ policy or Access Zone.
Issued: May 27, 2026
This advisory follows an investigation into a recent failover and failback event in a PowerScale environment. The investigation identified a OneFS SMB share configuration API concurrency limit that may affect environments running multiple failovers in parallel at scale.
What Happened
The primary root cause is a PowerScale API concurrency limitation. During parallel failovers, OneFS serializes writes to the SMB share configuration database. When a high number of SMB share configuration updates occur at the same time, the OneFS share API may exceed its safe write capacity and return the following error:
HTTP 409 AEC_CONFLICT — Conflict updating share(s): File exists
In the environment investigated, approximately 10 Access Zones with around 100 SMB shares each were failed over within a short time window. This resulted in elevated API response times and a percentage of share update requests returning HTTP 409 errors.
When This Occurs
This issue may occur during several stages of the failover/failback workflow, including:
- SMB share lockout during SMB Data Integrity processing
- Post-failover permission restoration
- Post-rollback permission restoration
Risk increases as the number of concurrent failovers and SMB share updates increases.
What Is Affected
The impact may include SMB shares left with unexpected deny permissions, permission-audit findings, or failover jobs entering a failed state when Block Failover on Warnings is enabled.
Who Is Affected
This advisory applies to you if you are running Eyeglass DR with PowerScale environments that have:
- Multiple failover/failback operations running concurrently
- A high number of SMB shares per SyncIQ policy or Access Zone
- SMB Data Integrity enabled
- Block Failover on Warnings enabled
Remediation
Stagger Failovers
Avoid running large numbers of failovers concurrently. Superna recommends failing over in smaller batches, ideally one at a time or no more than two at a time, with several minutes between batches.
Based on observed data, a reasonable working ceiling is approximately 10 concurrent share-configuration changes across all active failover jobs.
Evaluate Seamless SMB Failover
Where appropriate, consider enabling Seamless SMB Failover on a per-failover basis. This avoids the SMB share lockout and permission-restore workflow that triggers the high-volume OneFS share API write path.
Seamless SMB Failover changes the cutover behavior and relies on DNS, SmartConnect, and IP pool failover to redirect clients cleanly. Evaluate this option carefully before enabling it.
Contact Superna Support Before Planned Failover
If you manage large multi-zone PowerScale environments, contact Superna Support before your next planned failover or DR test.
A review can help validate:
- Failover batching strategy
- SMB share counts and OneFS API headroom
- Suitability of Seamless SMB Failover per zone
- DR readiness and SmartConnect alias state
- Additional tuning options where SMB Data Integrity is required
What Superna Is Doing
Superna is actively working on the following:
- Adjusting Eyeglass DR API rate limiting for high-frequency PowerScale APIs during parallel failover
- Engaging Dell regarding PowerScale API capacity considerations for high-parallel SMB configuration workloads
- The long-term solution will not depend on SMB API calls for the data integrity feature and will avoid the PowerScale concurrent SMB share update limitations
Next Steps
If you have questions, believe your environment may be affected, or are planning a DR test or failover involving multiple SyncIQ policies or Access Zones with large SMB share counts, contact Superna Support through your usual support channel and reference this technical advisory.