SRDF/S with a lot of invalids

Edward

Your Points are all valid, and your notion is correct. There will be performance implications if you have too many invalids when you switch to synchronous. It would be better to remain in Adaptive Copy, until you have almost caught up, as the IO will be held, due to the nature of Synchronous, waiting for an Acknowledgement before sending the next IO. In effect you have answered your own questions, which is good as you are on the correct track.

Hope this helps

Everything you always wanted to know about SRDF/S, but were afraid to ask.....

new IO's will be treated as synchronous but if it takes too long to get through the pipe because of invalids causing a bottleneck the host will feel the pain....rather sync in adaptive copy disk mode with a lot of invalids owed to remote

When you perform the switch from adaptive copy disk to synchronous mode any invalid track on disk is treated as adaptive copy disk mode is on.  Tracks already synch'd are treated as a synchronous I/O.  Once an invalid track is sent over the link it (synchronized) it is then treated as synchronous.  If it didnt work this way you would pretty much crash any host when you did a switch from AD-Disk to Synch mode.

Robert,

this would essentially mean that adaptive copy is not needed that long, since you could turn on SRDF in acp mode and switch to /S right after that. It would even be safe, since all invalid's will be copied in acp mode and anything that reaches the synchronised state will from then on continue in SRDF/S mode. Is this correct ? then why does EMC teach us to use acp mode until there aren't that many invalids left before switching to SRDF/S completely ? This doesn't make sence

OK, thanks for all your help - it's answered what was going in my mind, as I was trying to get my head around what happens when you do switch on SRDF/S.

Makes sense, but I realised it wasn't something I actaully knew the answer to.  Mostly I will be running catchup in adaptive copy, especially as it seems that should be faster overall.

Would it also be correct to say though, that until SRDF/S is synchronized, all the caveats for adaptive copy - that you don't necessarily have the tracks commited in the same sequence, and thus might end up with functionally corrupt data - would apply?

Hmm, I've obviously misunderstood something then. I was under the impression that adaptive copy didn't guarantee track sequence, meaning you didn't necessarily have a consistent copy. And assumed that would then extend to the SRDF/S when it's playing catchup.

No the data wont be corrupted.  In adaptive copy disk before data goes over the link data is written to cache by the host, destaged to disk then re-read and sent over the link unless the track in question is already in synch (not an invalid).

Think of SRDF as having a 3rd mirror position on your disks, its just not in the same physical array.

Adaptive copy does not give you a consistent restartable copy of data as all the data is not necessarily there between tracks.

Adaptive copy does not order writes.

If adaptive copy doesn't do it, does SRDF/S if you're starting with a large track skew? I'd assume not, and so much like in adaptive copy - until you're synchronized, you're not recoverable.

Quincy are you saying that when a track of data is sent over the link and marked as valid in adaptive copy disk it is not necessarily a valid track?

I did not say that it ordered the writes as it is a little hard to explain how srdf works in a forum.  If you update the same track of data three times it does not need to send all three updates over it only sends one update with the most recent data or if you are updating parts of a track one combined update.

Once the track is sent, it is valid.  Even before the track is sent, the track on the R2 is "valid", just not up to date with the R1 (an invalid from the R1 point of view).

In adaptive copy, the pool of tracks that need to be copied are sent in no specific order, which is why it isn't a good restartable copy.  Normally folks will take a BCV or Clone copy from the R2 before starting an adaptive copy session in order to keep a restartable copy in the R2.

If RDF/S is synchronized, each write will go across the link.  It can't send one write to cover multiple writes to the same track.

If we are talking about adaptive copy, many writes to the same place can be sent as one (the latest)

But in adaptive copy if there are two writes to two distinct tracks, the newest write on the R1 may not be sent to the R2 first, which is what I meant by ordered writes.