Start a Conversation

This post is more than 5 years old

Solved!

Go to Solution

1477

January 13th, 2016 11:00

SRDF/ACP - Transfer Period Time

SRDF/S uses FIFO technique - Realtime

SRDF/A uses cache based deltaset architecture - Data gets transferred once in 15 seconds [Default Cycle Switch Time]


I also understand SRDF/ACP is not a DR/restartable solution like SRDF/A & SRDF/S, but I would like to understand the transfer'period' time for SRDF/ACP mode.

Information from ECN:


With ACP each and every write made from host to array is copied to the target array - so if the host writes data to the same track (i.e. overwrites data) it will copy both writes across the link. Does it mean IO by IO? Without any delay?

From Document:

In adaptive copy write pending mode, data stays in cache until the SRDF emulation moves it across the SRDF links. --> Until? Not IO by IO?


In adaptive copy disk mode, the drive emulation writes data from cache to disk and schedules a request for the SRDF emulation to move data across the SRDF links. When data is scheduled to be sent across the SRDF links, the drive emulation, if needed, writes data back to cache. --> Scheduled? Any defined time period?

The SRDF adaptive copy modes allow the R1 and R2 devices to be more than one write I/O and up to the maximum skew value out of synchronization. By default, the maximum skew value is set to 65535 tracks. Once the maximum skew value is reached, the SRDF emulations must start the synchronization process to transfer updates across the SRDF links from the R1 to the R2 devices. --> Once the maximum skew value is reached? Does it mean transfer will not be kicked off until maximum skew value is reached i.e., 65535 tracks [4GB?]?

448 Posts

February 23rd, 2016 07:00

With ACP each and every write made from host to array is copied to the target array


If a track is updated with new data prior to the send only the updated information is sent. 


In adaptive copy write pending mode, data stays in cache until the SRDF emulation moves it across the SRDF links. --> Until? Not IO by IO? 


Data is constantly flowing over the links no it is not sent in an ordered manner.


When data is scheduled to be sent across the SRDF links, the drive emulation, if needed, writes data back to cache. 


ACP Disk mode allows data to be flushed from cache down to disk prior to the send; that data has to be read from disk up into cache then sent across the link to the target.  There is a lot going on in an array so a "scheduler" is in charge of tasks(SRDF sync, disk rebuilds, disk scrubbing for errors etc.).  When the array has "time" so to speak it does this and no it is not on a set schedule basis like every 5 minutes I do this.


Once the maximum skew value is reached? Does it mean transfer will not be kicked off until maximum skew value is reached i.e., 65535 tracks [4GB?]?


The entire lun can be completely out of sync this may be an old number.  Everything is tracked in hex numbers and the field used to only be FFFF (4 digits) to represent all tracks owed.  A device will start out fully owed to target and you start the sync with a command.  If a device has been partially sync'd or the links broken for some reason again you will do the recovery from where the device currently is when you issue the sync command.  The array does not wait for the device to hit a threshold and then start the sync process.


Most arrays running in an adaptive copy mode are only there for the initial sync to the target and when it gets close to sync is switched into its primary mode either SRDF/S or SRDF/A.

27 Posts

February 23rd, 2016 12:00

Thanks Robert.

No Events found!

Top