If you're using SRDF/S (Synchronous), or SRDF/A (Asynchronous), the replication target devices are consistent, but in WD (Write Disabled) state. That indeed qualifies as read-only, so a host connected to them will identify them, but not much else can be done with the target devices in that state. Especially since they continuously update their data from the source devices. For SRDF/S and SRDF/A only when you failover, or swap, the target devices take a RW (read-write) state.
If you want to operate SRDF where both sides are in RW state and replicate in both directions look into SRDF/Metro. It makes the SCSI personality of both source and target devices look identical to the host(s) when they are in sync, both sides are RW, and writes are replicated in both directions.
if target is ro the volume can not be read by a host.right?
i must break the srdf connection in order to read from volume?
what are the command to break the srdf and later to restore the srdf link?
sysmrdf split then symrdf restore?
when i restore all the data from primary site that was not written in secondary will be copied?
An R2 device may validly be in Write Disabled or Not Ready state when replication is active. You choose. So technically you can read from an R2, but as data changes from the R1 side, the changes will not be known and understood by the file system that the R2 is mounted on. It's not like NAS. So while it sounds good to read from the R2, in practice there are not many use cases (while replicating).
If you stop replication (split will make the R2 R/W), then you loos your DR position. Better to SNAP or Clone the R2 device and mount the local replica, depending on what you are trying to achieve.
What is your goal here?
the goal is to read from R2.In the future we need to write in R2.
So if we split srdf then R2 will be automatically rw?the data written in R1 while srdf is broken will be replicated if i restore srdf?
I recommend you take a look at the Pair States section in the SRDF CLI product guide: This will help you understand the R1, link and R2 states with the various SRDF operations.
A RESTORE operation makes the data on the R2 device the master and it will overwrite the R1 data. An ESTABLISH is the opposite, R1 is master.
Perhaps you can familiarise yourself with all of the available SRDF operations as it sounds like an SRDF SWAP may be useful to you if you want to write at each site from time-to-time. SWAP will make the DR site the R1 so you will not loose DR protection.