srdf/a vs srdf adaptive copy disk mode

Difficult to predict .. With ACP_DISK you transfer each and every write from the host to the target dmx. You simply allow the source to have invalids .. However there is no write folding so it's likely that two different writes to the same track triggers two different SRDF transfers between source and target.

SRDF/A captures writes in 30 second cycles. Within cycle boundaries, two (or more) writes on the same track will turn in a single track being transferred between source and target.

If your hosts tend to write almost always at the same place (locality of writes) hopefully SRDF/A have an edge. Considere also that SRDF/A allows you to enable DSE and Transmit Idle (that will deal with transient link problems) while ACP_DISK may drop if your problems last more then Link Limbo (10 seconds by default).

Switching from ACP_DISK to SRDF/A will hopefully give you a lower traffic between source and target, however keep in mind that it mainly depends on how hosts writes their data.

Also consider the fact that SRDF acp_disk mode (adaptive copy) is supposed to be a low priority replication from which currect production hosts should not suffer. When you choose to do the initial sync with /S or /A. this is a higher priority task and production hosts which use SRDF/S will suffer from this.
It is best practice to do the initial sync using acp_disk and when the target is (almost) identical to it's target, switch to /S or /A.

Adaptive copy offers no data consistency at the R2 side during a sync, this is because tracks can be sent over the SRDF link in any order - not the order they were written in. This allows the protocol to be very efficient at moving data.

Adaptive copy is therefore only suitable for initial bulk data transfers. Once the transfer is almost complete, switching to Sync or Async will take care of the consistency issue.

During an adaptive copy sync, if a host writes the same track a number of times and it has not been sent over the link - only the most recent copy is sent when it reaches the front of the RDF queue. This is analogous to the "write folding" which Async uses, except that it's not constrained by the async cycles. It's therefore possible that adaptive copy can make even more efficient use of the RDF link than Async can. It's also another reason why the R2 copy is inconsistent during the sync.

Anyway, to answer your question - the link mode makes very little difference to an initial replication because it only applies to new writes. Data which is already owed to the R2 is basically transferred in adaptive copy mode anyway.

The reason for explicitly selecting adaptive copy for an initial replication is to prevent a performance hit to the attached hosts for their new writes to R1s. If you leave the link in sync mode, new writes have to be acknowledged by the R2 before each host write can complete. The SRDF links will be very busy with the ongoing replication, so new synchronous writes & their acknowledgements can get delayed.

Finally, it's not possible to perform an initial replication in Async mode. The difference between source & target volumes is too great and the links will quickly drop.