For those people who use TrueCopy on a daily basis, you’ll know that the assignment of a TrueCopy pair is based on a source and target storage port, host storage domain and LUN. This means a LUN has to be assigned out to replicate it.
The part that has always worried me is the fact that the target LUN does not need to be in a read-only status and can be read-write.
Please, HDS to save my sweaty palms, change the requirement to make the target volume read-only before it can be a TrueCopy target….
If you enjoyed this article, please consider sharing it!
4 Responses to Trusting TrueCopy
Leave a Reply
You must be logged in to post a comment.
BTW, TC pair can be based on LDEV number, without defining port, host and LUN number.
Have you ever tried writing to the target LUN? From memory, if the copy status is “PAIR” then the S-VOL is read-only. If you go into PSUS mode, then you can write to the S-VOL, but the pairresync operation (COPY state) will copy over blocks modified on the P-VOL and those you have modified on the S-VOL.
I can’t rememebr which document it is in, but there is a table in one of the HDS documents that explains what you can do to the P-VOL and -SVOL in each ofthe different tru-copy states. It may have been teh CCI reference guide.
Yes, I was describing the initial process of creating a pair. I agree once a pair is established, then the S-VOL is read/only but not until then!
Krion, are you referring to creating the pair with CCI? Storage Navigator currently doesn’t allow this option – although I will double check CCI.
CCI definitely lets you use LDEVs now. I wish SN did the same.
I’m not so sure of the need for the read only before creating the pair. Unless maybe you’re running production on the remote system.