Hi,

Thanks for your question. Were there any errors prior to doing the split? Were their any pending writes? https://dell.to/3XUtbWb and https://dell.to/3kv41jb this may also help. https://dell.to/3EyxpvJ

Let us know if you have any additional questions.

@DELL-Josh Cr In my case, I never presented R2 devices to any host. These devices were added to the storage group, which doesn't have a masking view.

Symptoms
SRDF Failover issued.
SRDF Split issued.

Possible DU against R2 device depending on mounting dependencies on attached host.

symCLI command 'symdev show '  displays some FA paths for R2 device as Write Enabled, and others Write Disabled:
Example below:
Front Director Paths (4):
{
-----------------------------------
DIRECTOR PORT LUN
---------- ---- -------- ---------
Type Num Sts VBUS TID SYMM Host
-----------------------------------
FA 04F:0 WD 000 00 021 N/A
FA 07F:1 RW 000 00 011 N/A
FA 10F:1 RW 000 00 011 N/A
FA 13F:0 WD 000 00 021 N/A
}

Host reports paths as Write Disabled on SRDF R2 device after SRDF Failover or Split command issued.
Cause
If some FA paths for an R2 device have a Write status of Write Enabled, and others as Write Disabled, Solutions Enabler will not Write Enable the Write Disabled paths as intended during the SRDF Failover or SRDF Split command is issued.  This leaves the paths in mixed states which can lead some host operating system in an inability to correctly mount the R2 as intended.

This issue does not occur if all the FA paths for a given R2 device are ALL Write Enabled, or ALL Write Disabled.
Resolution
As a work-around, you can issue the following symcli command to bring the paths online:
symdev -sid rw_enable for an individual device
OR
symdev -sid rw_enable -devs : for multiple volumes in a range.

Additional Information
An R2 device can be made Write Disabled on an FA path via two scenarios:

Scenario 1:
SRDF Failover
SRDF Personality Swap
SRDF Establish
SRDF Failover or Split
If you add new FA paths between steps 3 & 4, the original FA paths are Write Disabled, and the new FA paths are Write Enabled.  At step 4 above, at SE 7.6.x, the mix of WE and WD paths will cause the SW to not enable the paths.

Scenario 2:
Individual FA path is made WD by customer via symdev write_disable command.
Again, if you have a mix of WE and WD for the R2, the SW can't distinguish and won't enable the WD paths.

A note About this state.

From the R2 side

If a device has been MANUALLY MANIPULATED thru ANY task outside of RDF SE does not change the state of the device on FA under any circumstances, establish, splt, suspend, resume, failover, failback.

From the R1 side.

If a device has been MANUALLY MANIPULATED thru any task outside of RDF, SE WILL  change the state of the device, but only on the failback. Establish, split, suspend, resume, SE will not change it. When the failback is issued, all the R1 devices change back to RW enabled on the FA.

This is working AS DESIGNED. This is not a bug. This is day one behavior. We will only manipulate the R1 devices on failback. Clearly the customer did some type of operation to manually manipulate a couple of the R2 devices thru the masking operation to be WD. When the failover to the R2 was issued, we will NOT manipulate the R2 devices that were manually changed. It s always been the philosophy to protect the R1 s.

@DELL-Josh Cr  https://dell.to/3XUtbWb and https://dell.to/3kv41jb these documents are not available for me to access. Could you please paste its contents here?